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
altogether
: { }
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
behave
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.
Larry
