"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.