Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!lll-winken!decwrl!crltrx!decvax!ima!esegue!compilers-sender
From: !gateley@m2.csc.ti.com (John Gateley)
Newsgroups: comp.compilers
Subject: Re: Obsession with lexical and syntactic issues
Message-ID: <1989Nov19.001553.9353@esegue.segue.boston.ma.us>
Date: 19 Nov 89 00:15:53 GMT
Article-I.D.: esegue.1989Nov19.001553.9353
References: <1989Nov15.193343.2017@esegue.segue.boston.ma.us>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: !gateley@m2.csc.ti.com (John Gateley)
Organization: TI Computer Science Center, Dallas
Lines: 26
Approved: compilers@esegue.segue.boston.ma.us
Posted-Date: 18 Nov 89 19:41:50 GMT

In article <1989Nov15.193343.2017@esegue.segue.boston.ma.us> worley@compass.com (Dale Worley) writes:
> [These are syntactic issues which arise in the real world.]
>- Constant revisions/changes to the grammar
>- Verifying that the new language features don't introduce ambiguities
>into the language
>- Automatically producing good error recovery from syntax errors
>- Language designers steadfastly refuse to make LALR(1) languages
>- Building a lex/parse system that will Do What I Mean

Lisp is a counter-example to most of the above points: Its grammar
is very simple (and modifications are made through the read-table
abstraction, instead of the parser). New language features don't
change the grammar, they are added as special forms or macros.
It is at least LALR(1), and parse systems are very simple. Lexers
are a bit harder, depending on how many special characters you use,
and whether you implement the Common Lisp read-table, but are not
more complex than conventional language lexers.

Good error recovery is still hard though, even with Lisp's simple syntax.

John
gateley@m2.csc.ti.com
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue.  Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.