Hi Moritz,
Thanks for the explanation, I appreciate it and I can certainly appreciate the
difficulty.
(Sorry for not getting back sooner, I missed your email until now.) It's a bit
of a shame since I expect most of the time .reduce will be called with a
closure. If the general solution can be had, that is mighty impressive. I sort
of oppose the notion that you can't provide a useful feature because the rarely
more useful general case is too difficult to implement right now (if it was my
task I'd be rejecting multis—forever) but I write a lot of Perl 5 too, and I
don't feel regret when I have to use a utility module to make up for something
that doesn't suit me and I'm happy to do the same in this case in Perl 6 for as
long as is necessary.
Best Regards,
Stephen
P. S. Thanks for all your work on Perl 6—that goes for everyone involved. It's
a great language whichever way you slice it.
> Subject: Re: [perl #78626] Patch: support higher arity in reduce()
> From: perl6-bugs-follo...@perl.org
> To: smosh...@hotmail.com
> Date: Thu, 13 Oct 2011 02:02:28 -0700
>
> Am 13.10.2011 06:01, schrieb smos...@loveandhotsauce.net:
> > That's fine, I think it was already shot down owing to the supposedly
> > dubious utility of supporting higher arities in .reduce()
> >
> > By the way, I submitted the patch because the error message had (and
> > still has) the "for now" wording when you try any other arity. But after
> > I submitted the patch I was asked to defend non-binary reduce. After
> > scratching my head I might have replied with some mumblings about
> > continued fractions or something, but I don't understand why I was asked
> > while that particular wording is still in place—either it's binary only
> > or it isn't, or perhaps it's just not specced.
> >
> > I can appreciate the added complication in checking when a non-binary
> > reduce should actually terminate, and other concerns. If I knew that the
> > functionality was desired, I'd be happy to submit another patch. At the
> > moment a change in the wording in src/core/List.pm might be advisable,
> > line 296: "fail('can only reduce with arity 2 for now')", dropping the
> > "for now" if the functionality is not in fact desired.
>
> Let me provide some context for the "for now" here. I'm not defending
> that phrase (and will remove it), just want to provide some food for
> thought.
>
> Back when you wrote the patch, we did find higher arity reduce
> desirable, and I think some of us are still emotionally attached to the
> idea.
>
> The problem is that the complexity of signatures makes it basically
> impossible to figure out which candidate to call if the reducer is a
> multi, and thus to decide how many arguments to pass.
>
> The idea back then was to somhow specific a mechanism for supplying a
> (possibly lazy) stream of arguments to a set of multi candidates, and
> have the call eat up an apropriate amount of arguments. Such a mechansim
> would be useful in other places as well (such as 'for' and 'map' with
> blocks of higher arity), and it would be a very nice anaolgy to regexes.
> And like the famous "longest token matching" [1] in regexes, we'd expect
> such a mechanism to be mostly greedy, ie the candidate that binds the
> most arguments wins, unless other circumstances prevent that from
> happening (you see, it's rather vague).
>
> I have no idea how feasible such a mechanism is, and if it will be
> included in Perl 6 at all. But I'm sure that if it will be defined, it
> will be on a much lower level than reduce -- probably in the multi
> dispatcher directly.
>
> Up to now such a spec hasn't happened, but the idea keeps simmering in
> the back of the minds of several Perl 6 hackers.
>
> Cheers,
> Moritz
>
>
