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
