I'm a little reluctant to commit to any specific modifications to optables at the moment because much of this will be significantly refactored in the relatively near future as part of implementing protoregexes and longest token matching into PGE.
As that's being done, I suspect we may discover a far superior mechanism for handling optables in general, including allowing multiple optables. I'm also not a fan of having proto subs (i.e., the operator token definitions) place themselves into the most recently defined optable. That sounds quite fragile, and it goes against the Perl 6 semantics that the grammar files are intended to be following. I do like the idea that the name of the $optable variable is based on the rulename, though -- that's definitely a step in the right direction. If we can come up with a better mechanism for associating operator tokens with the correct optable, then perhaps we should go with that. The ultimate answer will be to use protoregexes and categories, as STD.pm is currently doing. An intermediate answer might be to have an "is optable" trait for proto subs that can specify an optable to use other than the default. (Ideally the equiv/tighter/looser traits would also tie a new token to the optable of whatever it's being defined in relation to.) In particular, I don't want to provide too many new structures/ features that we may want to turn around and quickly deprecate when protoregexes come into play. Pm
