> +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: 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. -- Jonathan "Dataweaver" Lang
