On Wed, May 28, 2008 at 10:05:32PM -0400, Bob Rogers wrote:
> From: Allison Randal <[EMAIL PROTECTED]>
> >
> > Any of these alternatives can be marked as optional. Positional
> > parameters must come before all lookahead or named parameters. Lookahead
> > parameters must come before all named parameters. Positional, lookahead,
> > and named parameters must come before any slurpy parameters. And
> > required parameters must come before all optional parameters.
Note that "Positional, lookahead, and named parameters must come before
any slurpy parameters" is a significant change from the existing
spec, which allows slurpy positionals to appear before named parameters.
In fact, PDD03 seems to require this (although Parrot currently does not):
PDD03> So the acceptable ordering of targets is:
PDD03> * positional non-SLURPY (any number)
PDD03> * positional SLURPY array (optional)
PDD03> * NAMED non-SLURPY (any number)
PDD03> * NAMED SLURPY hash (optional)
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.
> These ordering constraints could be summarized as follows:
>
> positional < lookahead < named
> required < optional
>
> I assume you meant "order by positionality, then by optionality";
> otherwise, ordering a required named parameter vs. an optional
> positional parameter would be tough. That yields the following
> declaration order (ignoring :slurpy):
>
> Pos? Named? Reqd? => Example
> yes no yes => .param pmc A
> yes no no => .param pmc B :optional
> yes yes yes => .param pmc C :lookahead('c')
> yes yes no => .param pmc D :optional :lookahead('d')
> no yes yes => .param pmc E :named('e')
> no yes no => .param pmc F :optional :named('f')
>
> I can see why B has to be after A and before C, and I assume ":lookahead
> before :named" makes the implementation easier, but I can't see the need
> for any particular ordering of C vs. D, or E vs. F. Am I missing
> something? Just curious,
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.
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.)
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.
So my version of the above might be:
Pos? Reqd? Named? => Example
yes yes no => .param pmc A
yes yes yes => .param pmc B :lookahead('b')
yes no no => .param pmc C :optional
yes no yes => .param pmc D :optional :lookahead('d')
no yes yes => .param pmc E :named('e')
no no yes => .param pmc F :optional :named('f')
with :slurpy array occurring anytime after D, and :slurpy :named
hash occurring after F.
Pm
