> Well, Damian is indeed the soul of good taste. Just look at the Latin
> and Klingon modules. Hmm... maybe those weren't such good examples.
I SHOULD KILL YOU FOR THAT!
;-)
I'll release the latest draft of the parameter lists RFC early next week.
I think you'll find the syntax
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >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
>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 h
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!"
>
John Porter <[EMAIL PROTECTED]> writes:
> Damian Conway wrote:
> Well, as I mentioned in another recent parallel thread, if C is to
> be properly functionalized,
I deliberately stated "built-in functions", not "keywords".
Please consult Tom's list and my addendum:
Tom Christiansen <[EMAIL PRO
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
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, a
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 synt
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
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
> >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.
>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
>
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.
Whoa there! :-)
Not nec
>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
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.
Damian
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
C statements because I learned "no c
>Tom Christiansen wrote:
>> >Well, as I mentioned in another recent parallel thread, if C 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
Tom Christiansen wrote:
> >Well, as I mentioned in another recent parallel thread, if C 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 fin
>Well, as I mentioned in another recent parallel thread, if C is to
>be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
--tom
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) prototypin
> 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 impact (Damian)
> this a
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
>cur
22 matches
Mail list logo
