On Wed, Mar 23, 2005 at 05:43:52PM +0200, Yuval Kogman wrote:
: The algorithmic approach to binding some params:
:
: bind invocants
:
: bind named parameters, and keep leftover pairs for %_
:
: treat nonpairs as positionals, and bind them sequentially. Left
: over nonpairs get put in @_
This seems a little backwards--I think all positionals should be bound
before you start binding named pairs, if currying is to be consistent with
"ordinary" binding. Otherwise you can't catch binding explicitly to
a positional Pair argument. I also think doing it the other way leads
to weird situations where the first two positional arguments can
bind to, say, the first and third formal parameters, which is a situation
I'm trying to avoid. I'd like the transition from positional to named
processing to be irrevocable, at least in the case of ordinary binding.
But it's possible that .assuming() should be allowed to violate this,
if we let it do positionals at all. It would be a convenience to
allow positionals, but for a known function, you can get the same
behavior with named arguments.
: if we have slurpy params, they act as %_ and @_.
:
: package a sub with the bindings, and the unbound params, and
: return it.
: and, well... that's it.
:
: This has some funny properties, like:
:
: foo ($x) { ... }
:
: foo(x => 1, x => 2); # yields $x = 1, %_<x> = 2
I think that should probably be an error for a sub because it doesn't
have a signature that enables %_.
: foo(1, x => 2); # $x = 2, @_[0] = 1
There's where your scheme comes out backwards to me. I think it should
absolutely bind the 1 to $x, and then the x turns out to be extra, an
error in the case of a sub, and put into %_ in the case of a method.
But we can't have the situation of a positional argument being bound
to anything but the next positional parameter.
: (&foo.assuming(1))(x => 2); # $x = 1, %_<x> = 1
Would also be illegal for a sub, and put x=>2 into %_ for methods.
: Are these bugs? I could live with them, but they are a bit
: perl5-ish.
:
: I think we need a little more guidance, as the exact semantics of
: currying are not that well defined.
Another thing to think about is whether you allow application of
.assuming to a generic multimethod before it is dispatched. It would
be nice to be able to do that, and I can see that if multis don't
name their first parameters consistently, currying on position would
allow a dispatch that named currying wouldn't be able to express.
But more than anything I want to be able to curry a module or class.
And that's probably almost exclusively a named-argument thing,
unless you just happen to define every sub in your module to have a
consistent first argument type. But maybe, as with partial binding,
it's just sort of a partial dispatch, so say, if you curry a class with
an object as the first argument, it would curry the instance methods
but not the class methods. This seems pretty dwimmy to a human being.
(Or it could curry the class methods too if an object is allowed to
play the role of its class.)
Larry
