> Date: Wed, 22 Jan 2003 10:38:23 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> 
> On Tuesday, January 21, 2003, at 03:52  PM, Dave Whipp wrote:
> > But in a for loop:
> >
> >  for 1,2,3,4 { ... }
> >  for 1,2,3,4 -> ($a,$b) {...}
> >
> > its cuteness works because the brain sees it as a piping operator (even
> > though its not).
> 
> *** SPECULATION AHEAD ***
> 
> Note that C<for> allows you to name the arguments, using the pointy sub 
> rule:
> 
>      for @a -> ($a,$b) {...}
> 
> but note ALSO that it'd be great if C<map> and friends had that 
> capability, so you could C<map> two-at-a-time, etc.  (C<grep> and 
> C<sort> don't really need it, but I *suppose* you could use it for 
> grepping/sorting tuples.)

I'm not sure whether you know that this already is the plan.  The
following three are equivalent:

  my @a = map { uc } @b;
  my @a = map { uc $^a } @b;
  my @a = map -> $x { uc $x } @b;

And I believe two-at-a-time would also work.

> So we want the pointy-sub rule for C<map> and friends too:
> 
>      my @a = map -> ($a,$b) {...};   # pass to {...} 2-at-a-time, as $a 
> and $b
> 
> Pretty neat.
> 
> But ignoring pointy-sub for the moment, and assuming that we in fact 
> used -> and <- to mean pre/post-invocant (e.g. "pipes"): if we defined 
> C<for> as just another word for C<map>, what we really want is rules 
> such that *all* of the following work.  Question is, is it possible to 
> come up with something consistent.  Maybe.
> 
>      # void context
> 
>      @a.map {...}
>      @a.for {...}              # identical
>      @a -> map {...}           # identical
>      @a -> for {...}           # identical
> 
>      @a -> {...}               # identical (a cool shorthand when given 
> a closure?)
> 
>      for @a {...}              # Doh! This wouldn't work
>      for @a : {...}            # Hey, but this would (indirect object 
> syntax)
>      map @a : {...}            # identical
> 
>      for @a,@b,@c : {...}      # is this OK?
>      for (@a,@b,@c) : {...}    # OK, and better looking
> 
>      # list context
> 
>      my @a = @b -> for {...}
>      my @a = @b -> map {...}     # identical
>      my @a = map {...} <- @b     # identical
>      my @a = for {...} <- @b     # identical
> 
>      my @a <- map {...} <- @b    # identical
>      my @a <- for {...} <- @b    # identical
> 
> That works.  Pretty darn well, too.  (Note the critical bit, the 
> introduction of indirect object syntax to C<for>.)

Yeah, good point.  Why is it that C<for> and C<map>, so similar in
nature, accept such different forms for their arguments?

But, I'll have to admit,

  for @a,@b :-> $a, $b { ... }

Doesn't look quite as nice as the older version :->

I'm thinking it would be a very good idea to unify C<for> and C<map>
in their argument style.  I still think the distinction between
C<for>'s void and C<map>'s list context is a good one; i.e. don't make
them I<entire> synonyms.

But it seems natural to have C<for> a method of C<Array>, however
unnatural that seems.  I don't know, my thoughts are quite unclear at
this point; perhaps I'll write back when I've thought about this a bit
more.

Luke

Reply via email to