On Tue, Sep 06, 2005 at 06:19:01PM +0300, Yuval Kogman wrote:
: On Tue, Sep 06, 2005 at 13:28:24 +0000, Luke Palmer wrote:
:
: This should still work:
:
: > sub map (&code, [EMAIL PROTECTED]) {
: > gather {
: > my @args = @list.splice(0, &code.arity);
: > take &code([EMAIL PROTECTED]);
: > }
: > }
:
: multi sub foo ( ... ) { ... }
: multi sub foo ( ... ) { ... }
:
: my @mapped = map &foo ...;
:
: I think this is inconsistent.
:
: There is another option though:
:
: sub map (&code, [EMAIL PROTECTED]) {
: gather {
: take &code.mutably_bind_some(@list); # removes stuff
: # from @list
: }
: }
:
: The code object can then look for suitable multimethod alternatives
: for the arguments in question, avoid that alltogether, dispatch
: based on the arity of the first alternative, dispatch based on the
: arity of the most general alternative, or whatever.
Yes, I think that's closer to the mark. The basic problem is having
to deal with the arity *at all*, much as having to deal with string
positions as integers is becoming wronger as we get into Unicode.
What we're looking for here is a better abstraction, and I suspect that
this abstraction involves defining a class of dispatch that assumes an
implicit slurpy on the end of everything called, and simply returns
any unbound arguments as the "unshifted" part of the list. It could
maybe even be made to work right with respect to ? parameters that
might or might bind based on type.
It's very much like an inside-out .assuming, only it does the actual
call, and leaves the residue. Another view is that it's basically
turning a normal call into a mutator call of the splice variety.
So maybe map is just
sub map (&code, [EMAIL PROTECTED]) {
gather {
take @list.splice(&code);
}
}
or some such.
Larry
