On Thu, Sep 21, 2000 at 03:38:59AM -0600, Tom Christiansen wrote:
> > > 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 us
> > 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
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
[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, t
On 16 Sep 2000 22:11:25 -0400, Chaim Frenkel wrote:
>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.
OK. As long as flattenin
> "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.
> Does the prototype help guide the decision that it is a block and not
> an anon-hash?
Yes, as it does now in the existing prototype mechanism. For example:
use Data::Dumper 'Dumper';
sub takes_block (&) { print "takes_block: ", Dumper $_[0] }
sub takes_any
> I'm under the impression that "&" used in a function prototype signifies
> that the function takes a code block.
That's right. As I said in another post, I'm functioning rather poorly
just at the moment. :-(
Damian
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
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.
>
> Th
> "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 semicol
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote:
>> I view it as a mis-feature.
BL> I'm sorry to disagree. But flattening of argument lists is one of those
BL> things that make Perl, Perl. Change it, and it's not Perl anymore.
Sorry,
> >> 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
On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote:
>PS> Yes, please. I view the flattening of lists as a feature, not a bug, and
>PS> it has made Perl a lot easier to understand IMHO.
>
>I view it as a mis-feature.
I'm sorry to disagree. But flattening of argument lists is one of those
things
> "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 Frenkel
> "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 Pe
Eric Roode wrote:
> >
> >Also the ability to traverse multiple lists at once
> >
> > for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
>
> I don't get it. This is a great advantage over:
>@looparray = zip(@a,@b,@c);
>while ( ($a,$b,$c) = splice (@looparray, 0, 3))
> ?
>
Because splice() is destructi
> > You know, I would like to pass code blocks in any arg position;
> > I want sub foo(&\@&\@&) to be callable as
> >
> > foo { alpha() } @bravo { charlie() } @delta { echo() };
> >
> > No Cs, no commas.
Already in the RFC.
> And one further note: it would be nice if,
John Porter wrote:
>
> You know, I would like to pass code blocks in any arg position;
> I want sub foo(&\@&\@&) to be callable as
>
> foo { alpha() } @bravo { charlie() } @delta { echo() };
>
> No Cs, no commas.
And one further note: it would be nice if, given a prototype
which does
Graham Barr wrote:
> Also it hash been
> suggested that it could potentially replace each
>
> for my($k,$v) (%hash) { ... }
Continuing my crusade for beefier prototypes, I can easily envision this:
for(\$\$\%&);
callable as
for ($k,$v) %h { }
--
John Porter
We're
At 03:24 PM 8/29/00 -0400, John Porter wrote:
>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?
I mailed an RFC on multiple loop variables in for(
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.
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
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'
Exactly. We need a nondestructive slice. Some short piece of
syntax which expands
for [my](list of vars) (big list){ ... }
to
my @uniquelynamedcopy = (big list);
while ( [my](list of vars) = splice(@u15y,0,(length of list of vars))){ ... }
I think the absence o
At 12:43 PM 8/29/00 -0400, Steve Simmons wrote:
>On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> > Peter Scott wrote:
> > >Graham Barr once allowed as how he thought it would be neat if you
> could say
> > >
> > > for my($x, $y, $z) (@list) { ... }
>
>I too am pushing for this f
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> Peter Scott wrote:
> >Graham Barr once allowed as how he thought it would be neat if you could say
> >
> > for my($x, $y, $z) (@list) { ... }
I too am pushing for this feature, to the point where I'm considering
an rfc on the topic
On Tue, Aug 29, 2000 at 09:21:32AM -0400, Eric Roode wrote:
> I'm not seeing an earth-shattering advantage of:
>
> for my($k,$v) (%hash)
> over
> while(my($k,$v) = each %hash)
>
> AFAICT, they act the same, just look a little different.
> Eight characters difference, c
Graham Barr wrote:
>Maybe not with 3 variables, but how many people do
>
> my %hash = @_;
> { ... }
>
>so that they can process named arguments ?
>
>Having this would remove the need for the hash assignment. Also it hash been
>suggested that it could potentially replace each
>
> { ... }
I'm n
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> Peter Scott wrote:
> >Graham Barr once allowed as how he thought it would be neat if you could say
> >
> > for my($x, $y, $z) (@list) { ... }
>
> ObLanguageMinimalist:
>
> Um. Is this so frequently-used that the above syntax is pr
On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote:
> Well, I think it's likely that the perl6 parser would be made to
> handle this; but even if not, it shouldn't be too hard to get it
> to allow a ref to such a list:
>
> for [ $x, $y, $z ] ( @list ) { ...
I'm wondering how we ge
Peter Scott wrote:
>Graham Barr once allowed as how he thought it would be neat if you could say
>
> for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
?
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 t
33 matches
Mail list logo
