On Wed, Mar 23, 2005 at 11:53:06 -0800, Larry Wall wrote: > 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.
Currying and ordinary binding are implemented in the same
function... =P
> Otherwise you can't catch binding explicitly to
> a positional Pair argument.
soo... how would you diambiguate that in the general case?
Can I pass a named for an optional? or is that always a positionally
bound pair?
I'm reading through S06 a bit more in detail, and I see
Arguments destined for positional parameters must come before
those bound to named parameters.
Do pairs get slurped until there are no more required positionals to
fill in? In that case, how do you actually assign by name? Can you
mix positional and named params?
Going down further, I see:
sub formalize($text, +$case, +$justify)
This can we name text => "foo"? or will $text actually contain that
pair, as bound positionally?
> 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.
Yeah, that's why I raised this stuff here. Once I managed to
actually read Autrijus's code (not his fault!) I got thinking, and
wasn't sure the way it was done is the good way, since it seemed to
work, but was not really strechable to corner cases.
> 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.
Since we have .arity, why don't we make this a little more
introspectable too?
> : 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 %_.
And if it had a slurpy hash?
> : 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.
So again, how do we unambiguously tell apart a positional from a
named, when it's a pair? What's not yet bound? where we are in the
binding?
I think some concrete examples would be very good for me.
> : (&foo.assuming(1))(x => 2); # $x = 1, %_<x> = 1
>
> Would also be illegal for a sub, and put x=>2 into %_ for methods.
Ok. that's the consistency i want to attain. By that I mean:
foo( .... )
is the same as
(&foo.assuming .).(...)
.. ..
(&foo.assuming(.).assuming(.).assuming(.)).(.)
etc, given any syntax in '.' that stays the same.
> 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.)
I sort of agree with that, but i'm not sure... what if a named param
is missing? is it slurped? if we go that far, perhaps positionals
are the same?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!
pgpdT5mwSdamj.pgp
Description: PGP signature
