|Handling the typedef problem with a modifiable grammar firstname.lastname@example.org (1992-01-09)|
|Handling the typedef problem with a modifiable grammar email@example.com (Stephen J Bevan) (1992-01-13)|
|Programming language syntax design (was Re: ... typedef problem) landauer@morocco.Eng.Sun.COM (1992-01-14)|
|Programming language syntax design (was Re: ... typedef problem) firstname.lastname@example.org (Stephen J Bevan) (1992-01-15)|
|From:||Stephen J Bevan <email@example.com>|
|Date:||Mon, 13 Jan 92 16:12:30 GMT|
This message regards typedef names recognition problem.
So does this one :-)
[description of modifiable grammars deleted]
The following might seem like a flippant answer, but I am serious :-
One solution to the typedef problem, is to avoid it completely i.e. don't
bother trying to parse C and don't create any extensions of C. If you
really must parse C, use one of the hacks mentioned already i.e.
interogating the symbol table.
It seems to me that a lot of time is wasted trying to provide a solution
to something that is essentially broken. I'm disgusted at language
definitions that require hacks like symbol table interogation, or even
worse a modifiable grammar, just to be able to parse the syntax. C at
least has the excuse of being nearly 20 years old, but for newer
languages, there is no excuse at all. IMHO any person who designs a
grammar that needs additional help to be parsed, should have a _very_ good
reason for doing so.
For example, the problems caused by the same syntax for function calls and
array access in Ada is at least in part made up for by the fact that an
array can be swapped for a function very easily without having to change a
lot of code (an array is a discrete function after all). Having said that
I personally don't find this argument compelling, but at least it _is_ an
argument. I mean, just what is BK's or DMR's excuse for the typedef hack?
There have been (and are) too many languages that don't seem to have had
any real thought put to the design of the syntax. The designers seem to
start with "it should look like Pascal" or "it should look like C" and
blindly add syntax without giving it due consideration.
So please, any budding language designers/extenders out there, think long
and hard about about the syntax of the language and its impact on checking
context conditions (or static semantics if you prefer)
This is a heartfelt plea from somebody who has spent way too much time
poring over the definitions of languages like :- C, Pascal, Ada,
Oberon-2, ML, Haskell, ... etc. trying to make sense of their syntax and
Stephen J. Bevan firstname.lastname@example.org
PS Q: which language has the best syntax?
A: Lisp/Scheme, as there isn't any concrete syntax.
You program directly in the abstract syntax.
Makes writing the concrete -> abstract converter easy :-)
[On the other hand, some of us would put "easy to parse using yacc" fairly
low on our list of criteria for good language design. -John]
Return to the
Search the comp.compilers archives again.