Re: dynamic precedence, was Dangling else

Chris F Clark <cfc@shell01.TheWorld.com> 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

Return to the comp.compilers page.
Search the comp.compilers archives again.