Patrick R. Michaud wrote:
Since there's a fair amount of existing code that may be doing
slurpy positionals before named parameters, I propose, perhaps
as an interim step, that we say that positional slurpy array
parameters must come after all positional and lookahead parameters
(but could come before the named parameters), and any slurpy hash
must come after all lookahead and named parameters. This would
allow existing code to work while still preserving the proper
binding sequence.
It's tricky to decide where to put the positional slurpy with the
addition of lookaheads, which can be either named or positional, because
it won't slurp up the remaining positional arguments until they've been
bound to the lookahead parameters.
That would imply an ordering of:
* positional non-SLURPY (any number)
* lookahead non-SLURPY (any number)
* positional SLURPY array (optional)
* NAMED non-SLURPY (any number)
* NAMED SLURPY hash (optional)
Though, really there's no reason to require that the positional slurpy
come before named non-slurpy. So, let's relax the constraint and just
say "the positional slurpy must follow all other positional parameters
(including lookaheads)" and "the named slurpy must follow all other
named parameters (including lookaheads)".
Since we'll have to transition :named to :lookahead in many cases (in
whatever branch this is developed in), it shouldn't be much extra effort
to double check and make sure that any positional :slurpy parameters
also follow the :lookahead parameters.
C needs to come before D because all required positionals need to be
filled before we get to the optional ones. In fact, I think that
B and C should be switched above, so that required lookaheads are
filled before optional positionals. Otherwise we can end up with
a situation where a required lookahead cannot be filled because
the value was given to an optional positional.
Yes, you have to bind all required positional parameters before you bind
any optional parameters.
For any parameters that can be filled positionally, you can switch from
required to optional exactly once, and switch from positional to
lookahead exactly once, so you can switch to optional within the
lookahead parameters:
.param pmc A
.param pmc B :lookahead('b')
.param pmc C :optional :lookahead('c')
Or switch to optional within the positional parameters, in which case
all the lookahead parameters must also be optional:
.param pmc A
.param pmc B :optional
.param pmc C :optional :lookahead('c')
.param pmc D :optional :lookahead('d')
But you can never switch to optional in the positional parameters and
then switch back to required in the lookahead parameters:
.param pmc A
.param pmc B :optional
* .param pmc C :lookahead('c') # syntax error
.param pmc D :optional :lookahead('d')
And you can never switch back to positional parameters after switching
to lookahead parameters.
.param pmc A
.param pmc C :lookahead('c')
* .param pmc B :optional # syntax error
.param pmc D :optional :lookahead('d')
OTOH, I don't know that there will be many situations where
positionals and lookaheads are combined, so it may not be an
important issue. (And one can always "fix" things by converting
positionals into lookaheads with dummy names if an ordering needs
to preserved among the mixture.)
And, yes, there are options for munging the parameters otherwise if a
language has really complex parameter syntax.
Basically, pure positional parameters are a "strip out all the frills"
optimization. The argument binding code can always stupidly bind
positional arguments to positional parameters, one at a time, until it
runs out of arguments or runs out of pure positional parameters. It will
only pay attention to lookahead or named parameters once it's done with
pure positionals.
I agree that the ordering of E and F doesn't really matter to
any of the above -- for named only parameters the binding sequence
isn't important.
And agreed that the ordering of the named-only parameters doesn't really
matter, but for code maintenance sanity and possible future
optimizations, let's say that required named-only parameters must come
before optional named-only parameters.
Allison
