Tom Christiansen wrote:
I don't know what's happening with indirect objects, but the nastiness
whereby you can only use unsubscripted scalars is quite the crock.
You know, where you can say
print $fh "stuff\n";
and
$fh
But are not (well, in the second you can, but it's
Damian Conway wrote:
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Well, "indirect object
Tom Christiansen [EMAIL PROTECTED] writes:
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed
Peter Scott [EMAIL PROTECTED] writes:
I think you can't just leave it at that; the implication of this
requirement is that there should be a prototype for print's optional
filehandle.
I count on Larry's promise to do something about the indirect object
stuff.
-- Johan
John Porter [EMAIL PROTECTED] writes:
Damian Conway wrote:
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
I deliberately stated "built-in functions", not "keywords".
Please consult Tom's list and my addendum:
Tom Christiansen [EMAIL
John Porter writes:
Ah, the old "If you want Tcl, you know where to find it" non-argument.
"Closures?""No! This is Perl, not Lisp!"
"Objects?" "No! This is Perl, not Smalltalk!"
"Patterns?""No! This is Perl, not Snobol!"
"Subroutines?" "No! This is Perl, not Basic!"
Doesn't that tend to lead us in the direction of pack madness where we
end up with yet another 'sub language' within perl. We've already got
pack specifiers and regexen and the 'old' prototyping stuff. I'm not
arguing *against* these things you understand, I'm just vaguely
worried.
As you have
Tom Christiansen wrote:
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
Ah, the old "If you want Tcl, you know where to find
Tom Christiansen wrote:
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
Ah, the old "If you want Tcl, you know where to find
One function that takes an optional leading commaless arg:
sub print(handle? $FH, @)
or
Two functions differentiated by their prototypes
sub print(@);
sub print(handle,@);
I'm always forgetting the comma after the handlename in
Copen statements because I learned
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
I keep thinking of a * or a ... to
Basically, it "fixes" the indirect notation by making all of these Do
The Right Thing:
$r = new CGI (@args); # CGI-new(@args)
$r = new(CGI, @args); # CGI-new(@args)
$r = new(CGI @args); # CGI-new(@args)
It's all in the details (I'm sure you see the edge cases already, but
they're
I intend to extend the parameter lists RFC to cover optional
(non-trailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
Tom Christiansen wrote:
That's hardly the problem with indirect object syntax. Besides
what I just mentioned, there is the fact that it's acting in a
fashion that you could call stronger than a unary operator in terms
of precedence.
This is also mentioned in the RFC, although probably not
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current
Damian Conway wrote:
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 168
=head1 ABSTRACT
RFC 26
18 matches
Mail list logo
