On 8/24/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > 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.
>
> If losing the magic from =>'d pairs isn't buying us named args wherever we
> like, why are we contemplating it?
Well, that was one of the nice side-effects of the proposal, solving
something that had been bugging me. But the main reason for this
proposal was to demote Pair into a regular data type that wouldn't
sneak into somebody's named argument when we weren't looking. In the
Old Regime, I fear that I would never ever use Pair *except* for named
arguments precisely because I need to keep far too much information in
my head to use them safely.
> > so we should put some thought into making it syntactically trivial, if
> > not automatic like it is now.
The whole point was to deautomatize it! However, here's an
interesting solution: pairs are scanned for *syntactically* *on the
top level* of a function call (allowing named() or however we spell it
as a fallback when we want to be dynamic). However, :foo(bar) and foo
=> bar are equivalent again.
foo $x, $y; # two positionals, regardless of what they contain
foo $x, :y($y) # a positional and a named
foo $x, y => $y # a positional and a named
foo $x, (y => $y) # two positionals: $x and the pair y => $y
foo $x, (:y($y)) # same
In the fourth example, y => $y is no longer on the syntactic top
level, so it is not interpreted as a named argument.
>
> > I hate to say it, but the named args should probably be marked
> > with : instead of + in the signature.
That's pretty cool. Can't say I like the secondary sigil: it's really
not marking a property of the variable, but a property of the
parameter list. That information should probably be kept inside the
parameter list alone.
Luke
