Mark J. Reed wrote:
You anticipated me. So, is there a core method for
foldl/foldr/inject/reduce, or do you have to roll your own as in p5?
On 3/29/08, Larry Wall <[EMAIL PROTECTED]> wrote:
On Sat, Mar 29, 2008 at 10:18:53PM -0400, Mark J. Reed wrote:
: In general, is
:
: [op] (p1,p2,p3,p4...)
:
: expected to return the same result as
:
: p1 op p2 op p3 op p4...
:
: including precedence considerations?
Yes, in fact the section on Reduction Operators uses exponentiation
obliquely in one of its examples of something that should work
right-to-left. Admittedly it's not clearly stated there...
But the basic idea is always that the reduction form should produce
the same result as if you'd written it out with interspersed infixes.
It's a linguistic construct, not a functional programming construct.
It's not intended to be in the same league as foldl and foldr, and
is only just slightly beyond a macro insofar as it can intersperse
however many operators it needs to for an arbitrarily sized list.
It's not making any attempt to deal with anonymous first-class
functions though. Call a real function for that. :)
I think it would be powerful while not too difficult for Perl 6's "reduce"
to be able to do everything you'd get in functional programming, at least
some of the time.
Generally speaking, as long as the base operator is associative, then
[op] *$seq_or_array_etc
... should auto-parallelize with a deterministic result; or as long as the
base operator is both associative and commutative, then
[op] *$set_or_bag_or_seq_or_array_etc
... should also auto-parallelize with a deterministic result.
And then you get all the functional programming goodies. The first example
works for string catenation, but the second doesn't; the second does work
for sum|product|and|or|xor|union|intersection though.
Some base operators have an identity value in case the input collection is
empty, as is the case with the above operators, but others only work with a
non-empty input, such as mean|median|mode.
For other operators, non-assoc etc, the work will probably all have to be
linear. Eg difference|quotient|exponentiation.
Something I'm wondering, though, realistically how often would one actually
be reducing on an operator that is not associative? What practical use is
there for [-] (3,4,5) for example?
Are you just supporting that with all operators for parsing rule simplicity
as per a macro? I can understand that reasoning, but otherwise ...
I would think it makes sense to restrict the use of the reduction
meta-operator to just work over operators that are at least associative.
-- Darren Duncan
