On Fri, Aug 19, 2005 at 10:31:34AM +0000, Luke Palmer wrote:
: I propose that we move the magic out of the Pair type, and into a
: syntactic form.

That's kinda the direction we were already moving with the *%foo proposal,
so I think I like it, but I'll need to steep my brain in a bit more caffeine.

: Here's the best we have (from #perl6) at the moment:
:     a => b        # always a plain-vanilla pair, never a named argument
:     :a(b)         # always a named argument (in sub calls)
:                   # degenerates to a plain pair when not in a sub call
:     named(a => b) # make an ordinary pair (or list of pairs) into 
:                   # runtime named arguments
:     named(%named) # same

Offhand I don't like the name of named().  Actually, it's kind of a shame
we've already used :() for sigs, since we could say that :a(b) is :(a=>b).
Damian had a proposal at our meeting to demote sigs to methods, but
I've forgotten (or at least, haven't remembered) why that didn't fly.
Probably something about having to at least be a macro because the
parser has to start out at a different state inside.

Plus I still think it's a really bad idea to allow intermixing of
positionals and named.  We could allow named at the beginning or end
but still keep a constraint that all positionals must occur together
in one zone.

: This has a couple of advantages.  First of all, in the call:
:     foo($a, $b, $c)
: You *know* that you're passing three positionals.  It looks like what
: it is.  Also, you don't have to take extra cautionary measures if
: you're dealing with generic data.
: It's much less work for the runtime.  You don't have to scan for
: pairs, you just have the caller stuff them where you need them.

We already had it as pure syntax with the * proposal, albeit with the
=> still indicating named args.

: You only lose a *little* bit of flexibility at a great gain of
: usability of pairs.  That little bit is this ability:
:     my @args = (1, 2, 3, foo => 'bar');
:     baz([EMAIL PROTECTED]);   # $foo gets argument 'bar'

I suspect a lot of people would still prefer to write named args with =>,
so we should put some thought into making it syntactically trivial, if
not automatic like it is now.  Even making named() a listop would help.
I guess a downside to stealing :() is that it doesn't listopify readily,
and if you tried to, it would look weird, and you'd have to leave a
space after it.

    my @args = (1, 2, 3, :(foo => 'bar'));
    my @args = (1, 2, 3, : foo => 'bar');

Pity this doesn't work:

    my @args = (1, 2, 3, [:] foo => 'bar');

Maybe "where" as a term would work

    my @args = (1, 2, 3, where foo => 'bar');

Nah, people would omit the last comma and wonder why it's trying to
subtype 3.  Hmm.

    my @args = (1, 2, 3, plus foo => 'bar');

Assuming we stick with the + marker...

...since another little niggly inconsistency is that we'd be marking
named params with : on the call side but + on the receiving side.
I hate to say it, but the named args should probably be marked
with : instead of + in the signature.  Not sure what that does to
invocant colon though.  Probably requires that sigs with an explicitly
unnamed invocant start ($:...) or (Type:...) rather than just (:...).
Maybe that's not terribly important, since most invocants are either
entirely there or entirely missing.

: And you lose the ability to pretend that you're taking named arguments
: when you're not; that is, you say you're not being order dependent
: when you are.
: I think this is fixable with a trait on the sub:
:     sub form ([EMAIL PROTECTED]) is unnameable # refuse named parameters 
:     { }

More likely a trait on the slurpy.  Or maybe there's still room for
a type wider than Item on the slurpy array.  In either case it would
imply some kind of logic in argument unpacking that says, "I don't
have a place for named arguments, so splice any named list on the front
of the slurpy list."  Offhand I don't see a problem with that approach.

On the other hand, how else is the default p5-ish [EMAIL PROTECTED] going to 
when there's no sig?  (Though it's still a problem for methods that
generate *%_ for you, so we still need some explicit way to control
it on explicit slurpies.)

One other idle thought is that, if we don't mind blowing a different
kind of consistency, and if we s/+/:/ in sigs, a sig containing
:$foo could instead be written $:foo (presuming we take : away from
privates as we've postulated), which would get the colon next to the
name and have better visual correspondence with the :foo(), syntax,
and maybe even allow adverbs to include an optional sigil on the front.
On the other hand, then people would want to write $:foo in the body,
and that won't do.  So nevermind.  Stick with :$foo for that.


Reply via email to