On Fri, Feb 15, 2008 at 03:59:28PM -0800, Jonathan Lang wrote:
: > +Despite the appearance as a subscripting form, these names are resolved
: > +not at run time but at compile time. The pseudo-subscripts need not
: > +be simple scalars. These are extended with the same two-element list:
: > +
: > +infix:
: > +infix:['??','!!']
:
: Huh. I thought that multiple elements were only permitted in
: circumfix and postcircumfix, and that even there you had to use
: precisely two. Not that I'm complaining; but if this is a change of
: policy, we should consider the ramifications:
There are no such ramifications. These are merely names. The parsing
depends on the parts of the name only if the parsing rule chooses to
use them. In the STD grammar all such rules parse their pieces
explicitly, not by reference to the name.
: An infix operator with multiple delimiters must be list-associative;
: it must use the delimiters in order; and it must have one fewer
: delimiter than the number of positional parameters in the signature.
: Exception: if the signature includes a slurpy array, one more
: delimiter can be added to separate the slurped arguments. An infix
: operator with one delimiter is under none of these restrictions.
:
: A circumfix or postcircumfix operator can have three or more
: delimiters. In this case, the first and last delimiters get treated
: as the bracketing characters, and the bracketed contents get parsed
: using the remaining delimiter(s) as per the rules for infix operators
: (trimming off the leading parameter, in the case of postcircumfix
: operators).
:
: The only catch with this is that Conditional Operator Precedence is
: left-associative, not list associative. List-associativity would
: probably work as well or better for infix:; but this precedence
: level also includes ff and fff.
Indeed, going down this path opens several cans of worms. This is
better solved explicitly from within the parsing rule itself in the
rare cases that you want to anything so complicated. Boiled down,
the rule for the standard conditional operator is just:
token { '??' '!!' }
and the allowed precedence in the middle is both evident and succinct.
Normal parens are parsed as:
token { '(' ')' }
I see virtually no need for Another Way To Do It in this case. It would
only contribute to the befuddlement of the masses.
Larry
