Allow operators to be defined in other, "expression-like" rules

[masak]

I was a little taken with how owl (#426) allows operators to be declared. Briefly, an expression is made up of an alternation of different subrules, plus whatever (prefix, infix, postfix) operators might apply to those. Crucially, this is possible with any rule, not just EXPR.

I've gotten used to the reflex of thinking "that would be an operator and people often call it one, but it isn't because it's outside of EXPR, where operators live". (See e.g. #250 (comment).)

What if I had that one exactly backwards? 🙂 What if basically everything that looks like an operator is one?

Amazingly, I'm finding immediate use for this. 007 wants me to define it this way. Here are the examples I've been able to think of so far:

• A parameter list is an alternation of one thing: identifier. The default infix operator is infix:<,> but all the extra syntax discussed in Make it possible to switch on optional parameters/parameter defaults/rest parameters #112 can be phrased in terms of (macro) operators. In fact, Make it possible to switch on optional parameters/parameter defaults/rest parameters #112 (comment) turns from something embarrassingly hard to something near-trivial when we think of this in terms of operators.
• An argument list is an alternation of one thing: EXPR. The default infix operator is infix:<,> but we've been discussing providing prefix:<...> as an additional one. (Just never in those terms.) There are also interesting opportunities involved in making two optable parsers be adjacent like that. Should they be merged in the parser?
• A statement is a proto rule, and so a kind of honorary alternation. Decorators can be expressed as is parsed prefix operators on statements. Honestly, that makes almost too much sense. Something can sort out the details of trying to decorate something un-decoratable. Other things, such as fields and methods can also be decorated in the same way.
• The commas inside of the { } in an import statement are also a candidate.

In short, everyone needs a little bit of that operator love, not just EXPR.

I don't have a super suggestion for syntax, but I was thinking something like parameter:postfix:<?> might suffice.

[masak]

Wherever there are commas, there's another instance of these "expression-like" sublanguages. (In fact, those that have commas or some similar separator should maybe be referred to as "list sublanguages" or some such.) In each case, the desire to extend such sublanguages with custom (yes!) operators seems to be greater than zero.

In fact, I forgot to mention array and object literals as two more examples of this. Examples of extensions include (for both) the spread operator, and (for objects) the computed key syntax.

I forgot to mention that all these comma forms will want to allow "trailing" (maybe with a decorator @trailing), that is, even though they are infixes, they allow the lack of an rhs, in which case they act as a no-op.

Dear me, it feels like we have the right abstraction all of a sudden! New opportunities are revealing themselves all the time.

Almost all of these operators in these expression-like languages are macros, by the way. Pretty sure that's because (since we're not in EXPR) we're not actually evaluating expressions; instead, we're constructing AST for the compiler/runtime to consume in other ways. For example, the first comma in a parameter list takes a parameter list value on the left and a parameter on the right, and reduces them both to a larger parameter list. (All the commas are "reducing" in this way; there's a fixed pattern here that we could exploit -- some way to declare these commas by just passing in their two analogues of parameter and parameter list.

Any rule which is an alternation (or a proto) is automatically an extension point for these expression-like sublanguages.