|Handling the typedef problem with a modifiable grammar email@example.com (1992-01-09)|
|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)|
|Re: Programming language syntax design (was Re: ... typedef problem) email@example.com (1992-01-17)|
|Re: Programming language syntax design (was Re: ... typedef problem) firstname.lastname@example.org (1992-01-20)|
|From:||email@example.com (Dr A. N. Walker)|
|Keywords:||syntax, parse, design|
|Organization:||Maths Dept., Nott'm Univ., UK.|
|Date:||Fri, 17 Jan 1992 17:34:53 GMT|
In article 92-01-057 landauer@morocco.Eng.Sun.COM
(-8 Doug Landauer 8-) writes:
>> [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]
I'm not too worried about Yacc in particular, but I think "easy to
parse automatically" needs to come fairly high up -- see below.
>On the other other hand, I would expect "easy for humans to parse quickly"
>should be very high on everyone's list.
A successful language must be easy to (a) write [else no-one will
use it]; (b) read [else it will be unmaintainable]; and (c) parse [else
implementations will be expensive and rare]. Anyone [poetic licence!]
can write a Pascal parser -- so Pascal compilers are ten-a-penny, every CS
student studies them, and Pascal is (or was until recently) popular well
beyond the intrinsic merits of the language. Contrariwise, Algol is a pig
for amateur compilation, and languishes despite its merits.
>[...] if the lexer
>and/or parser have to jump through hoops to classify a construct, then so
>does the *person* trying to read this code.
This doesn't follow. Traditional lexers and parsers take a
microscopic view of the code (typically based on "what is the next
symbol?"). Human readers typically take a more global view, even on first
reading. I don't carry a symbol table in my head, so I expect to have to
refer back *or ahead* in the code to discover what some variable "is"; I
can make use of comments or the names of variables to intuit what some
code is trying to do; layout often helps to give the global structure of
the program. Of course, if the programmer writes obfuscated code, *then*
the human may have to jump through the same hoops.
Andy Walker, Maths Dept., Nott'm Univ., UK.
[I'd expect that the obstacles to Algol60 implementations are call-by-name
and the lack of standardized I/O. On the other hand, Algol68 is indeed
difficulto to parse. -John]
Return to the
Search the comp.compilers archives again.