Re: dynamic precedence, was Dangling else

Chris F Clark <cfc@xxxxxxxxxxxxxxxxxxxx> writes:

However, from a software engineering perspective, allowing users to
reassign ("fix") the precedences does not simplify the problem. It
makes it worse. Now, when writing an expression, one has to know
whether the default rules apply or some "fixed" set. Thus, when
writing defensive code, one has to protect against not only the
follies of the original language designer, but also the follies of the
other authors of the current application one is working on. The
result is that one cannot trust that the code one is looking at does
what one expects, unless one knows the context.

Summary: adding compile-time operator precedence is actually
easy. Doing so is not necessarily wise. What we really need is ways of
taking the "shortcuts" out of languages and making such shortcuts
explicit. When we have that, adding user configurable operator
precedence and other shortcuts may be beneficial, because the reader
can take them back out and get back to a simpler (if less terse)
language where the steps are more explicit. One won't do that
everywhere, just in the cases where the interactions are unclear.

Perhaps, I'm just becoming reactionary.

I quite agree with you. I find that all kinds of syntax extensions
(macros etc.), while allowing more compact code, often require a good
deal of context knowledge to parse (for the human reader).

In terms of user-defined operator precedence, I think a reasonable
solution would be to define a reasonably deep hiearchy of standard
operators and say that user-defined operators get a priority based on
the symbols they contain. For example, a user-defined operator "+<"
will get the same precedence and associativity as "+", as "+" is the
first character in the name of the user-defined operator.

The initial set of operators must be designed so operators with
different priorites must have distinct start characters, so you can't
have both "+" and "++" with different priorites, nor can you have both
binary and unary minus sharing the same name. Some languages (e.g.,
SML) use other symbols such as "~" for unary minus anyway, so I don't
think this is much of a problem. Note that different characters may
have the same precedence. For example, you would want "=", ">" and
"<" to have the same precedences (which would imply the same for "<=",
">=", "=/=", "<>", etc.).

In addition to making it easier for a human reader to parse
expressions with user-defined operators, it also makes it easier to
use standard lexer and parser generators.

Torben
.