Re: User friendly compiler-compiler tools

anton@complang.tuwien.ac.at (Anton Ertl)
Mon, 2 Oct 1995 19:15:02 GMT

          From comp.compilers

Related articles
User friendly compiler-compiler tools faase@cs.utwente.nl (1995-09-18)
Re: User friendly compiler-compiler tools anton@complang.tuwien.ac.at (1995-10-02)
User friendly compiler-compiler tools fjh@cs.mu.OZ.AU (1995-10-14)
Re: User friendly compiler-compiler tools fjh@cs.mu.OZ.AU (Fergus Henderson) (1995-11-09)
| List of all articles for this month |

Newsgroups: comp.compilers
From: anton@complang.tuwien.ac.at (Anton Ertl)
Keywords: tools, parse
Organization: Compilers Central
References: 95-09-121
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.,


Algebraic laws:
a+b+c=(a+b)+c=a+(b+c)


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.


Intuition:
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 )
          | base_case
          ;


If you think it's necessary, add a few rules for implicit
parenthesizing; when in doubt, require explicit parenthesizing.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html
--


Post a followup to this message

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