Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
I'm not a prototype person (in fact RFC 128 makes it a hanging offence
to use that confusing word in connection with parameter lists! ;-)
Could someone
[This somewhat elderly draft was found lying about an edit
buffer, but I do not believe it was ever sent yet.]
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent,
Tom asked how we'd deal with variadic subroutines without sacrificing
compile-time information (i.e. parameter lists).
Below I've indicated how RFC 128 would handle the cases he lists.
To recap: RFC 128 proposes that parameters may be given a C:repeat
attribute to make them variadic within a
"BL" == Bart Lateur [EMAIL PROTECTED] writes:
BL I'll give one example.
BL sub min {
BL my $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
chaim
--
On 16 Sep 2000 22:11:25 -0400, Chaim Frenkel wrote:
BLsub min {
BLmy $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
OK. As long as flattening a list
"DC" == Damian Conway [EMAIL PROTECTED] writes:
How would the parser handle this? Some '}' would need ';' some don't.
DC The trailing C parameter specification tells the parser that there
DC the last argument will be a raw block and that it need not be a followed
DC by a semicolon. It's no
From: Damian Conway [mailto:[EMAIL PROTECTED]]
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need
';' some don't.
The trailing C parameter
On 11 Sep 2000 13:47:22 -0400, Chaim Frenkel wrote:
Sorry, I don't see list flattening as _fundemental_ to perl. It is
just the way it is currently done. Could you tell me how it could be
_fundemental_?
I'll give one example.
sub min {
my $min = shift;
foreach
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
The trailing C parameter specification tells the parser that there
the last
"PS" == Peter Scott [EMAIL PROTECTED] writes:
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
PS Yes, please. I view the flattening of lists as a feature, not a bug, and
PS it has made Perl a lot easier
"DC" == Damian Conway [EMAIL PROTECTED] writes:
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
chaim
--
Chaim Frenkel
Jonathan Scott Duff wrote:
I'm wondering how we get both
for ($x,$y,$z) (@array) { ... }
and
for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it's all
At 02:57 PM 8/29/00 -0400, John Porter wrote:
But as for the semantics... how does perl handle this:
for ($x,$y,$z) (@a1,@a2) { ... }
and
for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
Making the case where the number of iterators == the number of arrays
special may not be so good.
Peter Scott wrote:
Yes, please. I view the flattening of lists as a feature, not a bug, and
it has made Perl a lot easier to understand IMHO.
So... is an RFC forthcoming? Or shall I?
--
John Porter
We're building the house of the future together.
Peter Scott wrote:
for my($x, $y, $z) (@list) { ... }
...
IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
was could say whether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Well, I think
15 matches
Mail list logo