Thomas A. Boyer writes:
> Michael Lazzaro wrote:
> > *Now*, what to do about the fantastic magic that pointy-sub provides?
> > The _spectacular_ win would be if we could just recognize an optional
> > parameter list as part of a block.
> >
> > map @a : ($a,$b) {...} # params + closure = closure with params?
> > for @a : ($a,$b) {...}
> >
> > So that anywhere you had a closure, you could put a paramlist in front
> > of it. Not likely we could get that to work, since best-case scenario
> > it would probably barf on $a and $b being undefined before it ever got
> > to the closure. But it might be possible, at the expense of some
> > parser complexity.
>
I sertainly can do it like taht :
map @a : {...} is sig($a,$b)
for @a : {...} is sig($a,$b)
or
map @a : sub($a,$b) {...}
for @a : sub($a,$b) {...}
or
@a ~> map sub($a,$b) {...}
It also seems that the difference between map and for may be twisted
as follows : map apply particular closure to several ( possibly one )
array , while for takes particular array ( which may have possibly
passed some pre -zipping/-weaving) and apply pour it to several (
possibly one ) closures.
if we assume that for can accept as its last arguments sequence one or
more closures than with the existing pointy sub meaning of -> we can
have
for @a -> ( $x ){ ... }
-> ( $y ){ ... }
-> ( $z ){ ... } ;
and "," is unnecessary after the curly for the same reason it is
unnecessary after @a.
since grep/map/and_friends are just subroutines this naturally gives
piping behaviour :
for @a -> ( $x ){ ... } #this is map
,grep -> ( $y ){ ... } #this is grep
,sort -> ( $a,$b ){ ... } ; #this is sort
this is similar to the old "then" suggestion of Damian Conway
@a then map -> ( $x ){ ... } #this is map
then grep -> ( $y ){ ... } #this is grep
then sort -> ( $a,$b ){ ... } ; #this is sort
arcadi
