"David Storrs" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > And then we can replace the ~> with ->:
> >
> > for 1,2,3,4
> > -> sub ($a, $b) { $a+$b }
> > -> sub ($a) { $a**2 }
> > -> { $^foo - 1 }
> > -> print;
> >
> > And this begs the question: what exactly does the C<for> contribute to
> > the semantics of the pipeline? What would C<map> (in void context)
> > do differently?
>
> One potential answer: make 'map' be lazy by default and 'for' be
> nonlazy (energetic? active? ADHD?). My logic in suggesting it this
> way around is that, to me, 'for' seems to operate more on a whole
> list, while 'map' is intended to operate on elements one after
> another. Like so:
>
> for (1,2,3) { print } # "I want to call print for this whole list"
> map { print } (1,2,3) # "Map the 'print' function over the elements
> # of this list"
I have a feeling its the other way round:
(1,2,3,4) ~> map { print }
Vs
for 1,2,3,4 -> print
The "obj ~> method args" form calls the method on the object. C<map>
is then a method (called on the entire list) that calls its codeblock for
each member
The "for list -> sub" would call the sub for each member of the list. Hence
an equivalence:
for list -> { per-elem code }
eq
list ~> map { per-elem code }
But remember, this is all getting very hypothetical: -> doesn't (currently)
mean "L2R pipe into sub"
Dave.
