|Re: Dangling else email@example.com (SM Ryan) (2006-02-24)|
|Re: Dangling else firstname.lastname@example.org (Russ Cox) (2006-02-24)|
|Re: Dangling else Brian.Inglis@SystematicSW.ab.ca (Brian Inglis) (2006-03-11)|
|Re: dynamic precedence, was Dangling else cfc@shell01.TheWorld.com (Chris F Clark) (2006-03-12)|
|Re: dynamic precedence, was Dangling else alexc@TheWorld.com (Alex Colvin) (2006-03-14)|
|Re: dynamic precedence, was Dangling else email@example.com (2006-03-14)|
|Re: dynamic precedence, was Dangling else firstname.lastname@example.org (Tony Finch) (2006-03-15)|
|Date:||14 Mar 2006 00:49:51 -0500|
|Organization:||Department of Computer Science, University of Copenhagen|
|References:||06-02-154 06-02-168 06-03-024 06-03-038|
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).
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.
Return to the
Search the comp.compilers archives again.