At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
> I would think you actually want to be able to define grep, map, et al.
> in terms of the mechanism for unraveling, and just let the optimizer
> collapse the entire pipeline down to a single map.
Even for map and grep this is a bit trickier, since map can produce
zero or more values for each input value, and calls its body in list
context, whereas grep produces zero or one value, and gets called in
scalar context. So you'd need something like a full call and return
prototype for each mapping function, e.g.:
Function Return context Argument context
-------- -------------- ----------------
-> $a { $a + 2 } ($y) ($x)
grep(&block) ($y is optional) ($x)
map(&block) ([EMAIL PROTECTED]) ($arg)
Then your loop merging macro could deconstruct these into the
appropriate kind of loop (using foreach and pushing single items only
to make intention clear):
@a ==> map &b ==> @c
==>
foreach $a (@a) { foreach $b (map_item(&b, $a)) { push @c, $b } }
@a ==> (&b = -> $a { $a + 2 }) ==> @c
==>
foreach $a (@a) { push @c, b($a) }
@a ==> grep \&b ==> @c
==>
foreach $a (@a) { foreach $b (grep_item(&b, $a)) { push @c, $b } }
where "map_item" and "grep_item" are the single-element mapper
functions defining map and grep. I think that both the context and
the number of items consumed/produced could be gathered from
prototypes, so the only restrictions for mapping functions would be
(1) having a prototype available at definition time, and (2) being
side-effect-free.
/s
