Re: dynamic precedence, was Dangling else (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
14 Mar 2006 00:49:51 -0500

          From comp.compilers

Related articles
Re: Dangling else (SM Ryan) (2006-02-24)
Re: Dangling else (Russ Cox) (2006-02-24)
Re: Dangling else (Brian Inglis) (2006-03-11)
Re: dynamic precedence, was Dangling else (Chris F Clark) (2006-03-12)
Re: dynamic precedence, was Dangling else (Alex Colvin) (2006-03-14)
Re: dynamic precedence, was Dangling else (2006-03-14)
Re: dynamic precedence, was Dangling else (Tony Finch) (2006-03-15)
| List of all articles for this month |

From: (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
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
Keywords: syntax, design
Posted-Date: 14 Mar 2006 00:49:51 EST

Chris F Clark <> 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.


Post a followup to this message

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