[KIP] - syntax priorities wildcard

Start with issue #2219 and the production in kast.k to understand the intended priority behavior. Review the existing frontend handling and tests for casts, K sequences, and rewrites. Done means wildcard priority declarations generate the equivalent grammar relations and existing tests continue to pass.

Motivation

• Sometimes it is desirable to express a priority relation saying that all syntax has a looser or tighter priority than particular pieces of syntax. This is generally of use when defining syntax that is part of the K language itself, but it may have other applications
• Right now such code needs to be explicitly encoded as code in a disambiguation pass in the K frontend, making it time consuming and error prone to add new cases or pieces of syntax. It would be nice if we could express such priority relations directly in K and have the correct grammar be automatically generated.

Example K Code

syntax priorities #SyntacticCast > *
syntax priorities * > #let > #KSequence > #KRewrite

Documentation

If the user writes syntax priorities foo bar > baz qux > *, it is identical to if the user wrote:

syntax priorities foo bar > baz qux
syntax priorities foo bar baz qux > *

The first sentence above has a pre-existing meaning in K. The meaning of the second sentence would be that any symbol other than foo, bar, baz, or qux should be treated as having lesser priority than each of those four symbols.

Similarly, if the user writes syntax priorities * > foo bar > baz qux, it is identical to if the user wrote:

syntax priorities foo bar > baz qux
syntax priorities * > foo bar baz qux

The meaning of the second sentence above is that any symbol other than foo, bar, baz, or qux should be treated as having greater priority than each of those four symbols.

Potential Alternatives/Work-arounds

Since we are expressing that any new syntax would be subject to this priority relation, even if it has not yet been declared in this module, it is impossible to express such a priority relation using existing K features. The only possible workarounds would be to either modify the K frontend to add such a case, or else to explicitly use parentheses or manually add priority rules covering each case of concern. None of these solutions are particularly desirable, although the modification of K code may suffice if we do not have to make changes frequently. However, such a solution is prone to bugs, not to mention being hard to document for users.

Testing Approach

See issue #2219 for an example test case that could be used if we added the production syntax priorities * > #let > #KSequence > #KRewrite to kast.k. Existing test cases ought to also serve as adequate testing for this feature since it would replace existing solutions for casts, ksequences, and rewrites.