|User friendly compiler-compiler tools firstname.lastname@example.org (1995-09-18)|
|Re: User friendly compiler-compiler tools email@example.com (1995-10-02)|
|User friendly compiler-compiler tools firstname.lastname@example.org.OZ.AU (1995-10-14)|
|Re: User friendly compiler-compiler tools email@example.com.OZ.AU (Fergus Henderson) (1995-11-09)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||Mon, 2 Oct 1995 19:15:02 GMT|
|> Are there also compiler construction tools that focus on
|> user-friendliness? For example I would like to write:
|> expr := "(" expr ")"
|> | expr "*" expr PRIO 1 L
|> | expr "/" expr PRIO 1 L
|> | expr "+" expr PRIO 2 L
|> | expr "&&" expr PRIO 3 R
|> | var_ident.
|> Such that "(a && b) * c / d + e && f && g" is read as:
|> ((((a && b) * c) / d) + e) && (f && g)
This is a bad idea. Everyone who ever read a program differently than
the compiler knows what I mean. Normal BNF is already too powerful,
because it makes it too easy to design complicated syntaces.
Now you propose to make it easier to make a very common error in
syntax design: an expression syntax that requires too few explicit
parentheses, inviting misunderstandings between humans and compilers.
E.g., you would have "d+e&&f" mean "(d+e)&&f". Why? Assuming that the
operators have the same meaning as in C, "d+(e&&f)" is just as
meaningful (and probably more common) than "(d+e)&&f". The solution of
course is that the programmer should specify explicitly (with
parentheses) what she means.
There are only a few exceptions: We have learned some precedence rules
in school for many years, some precedence rules seems to be intuitive,
and in some cases algebraicic laws (associativity) make parentheses
unnecessary. In these cases the parentheses can be left away with
little danger of misunderstanding. E.g.,
What we learn in school:
a+b*c = a+(b*c)
Note that in school we always use the "a \over b" notation, which
performs explicit parenthesising, so we do not learn a precedence for
"/" in school. Even three years of studying computer science have no
impact in this respect on many people.
a+b<c = (a+b)<c
a<b&&c = (a<b)&&c
but a+b&&c has no intuitive resolution.
So, when you design your next programming language, use a simple
expression grammar like
expr: expr1 op expr1
| op expr1
expr1: ( expr )
If you think it's necessary, add a few rules for implicit
parenthesizing; when in doubt, require explicit parenthesizing.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.