Re: Programming language syntax design (was Re: ... typedef problem)

anw@maths.nott.ac.uk (Dr A. N. Walker)
Fri, 17 Jan 1992 17:34:53 GMT

          From comp.compilers

Related articles
Handling the typedef problem with a modifiable grammar bburshte@pyrps5.eng.pyramid.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) bevan@computer-science.manchester.ac.uk (Stephen J Bevan) (1992-01-15)
Re: Programming language syntax design (was Re: ... typedef problem) anw@maths.nott.ac.uk (1992-01-17)
Re: Programming language syntax design (was Re: ... typedef problem) bliss@sp64.csrd.uiuc.edu (1992-01-20)
| List of all articles for this month |

Newsgroups: comp.compilers
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Keywords: syntax, parse, design
Organization: Maths Dept., Nott'm Univ., UK.
References: 92-01-043 92-01-057
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.
anw@maths.nott.ac.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]
--


Post a followup to this message

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