Re: Philosophical question regarding statement terminators

Chris F Clark <cfc@world.std.com>
14 Nov 2000 13:10:00 -0500

          From comp.compilers

Related articles
Philosophical question regarding statement terminators steve@brazzell.com (Steve Brazzell) (2000-11-07)
Re: Philosophical question regarding statement terminators tmoog@polhode.com (Tom Moog) (2000-11-09)
Re: Philosophical question regarding statement terminators cfc@world.std.com (Chris F Clark) (2000-11-09)
Re: Philosophical question regarding statement terminators jthorn@galileo.thp.univie.ac.at (2000-11-09)
Re: Philosophical question regarding statement terminators vbdis@aol.com (2000-11-11)
Re: Philosophical question regarding statement terminators wclodius@aol.com (2000-11-14)
Re: Philosophical question regarding statement terminators cfc@world.std.com (Chris F Clark) (2000-11-14)
Re: Philosophical question regarding statement terminators jerrold.leichter@smarts.com (Jerry Leichter) (2000-11-14)
Re: Philosophical question regarding statement terminators cfc@world.std.com (Chris F Clark) (2000-11-15)
Re: Philosophical question regarding statement terminators vbdis@aol.com (2000-11-17)
Re: Philosophical question regarding statement terminators vbdis@aol.com (2000-11-19)
Re: Philosophical question regarding statement terminators adrian@sartre.cs.rhbnc.ac.uk (A Johnstone) (2000-11-21)
Re: Philosophical question regarding statement terminators cfc@world.std.com (Chris F Clark) (2000-11-25)
| List of all articles for this month |

From: Chris F Clark <cfc@world.std.com>
Newsgroups: comp.compilers
Date: 14 Nov 2000 13:10:00 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 00-11-069 00-11-090
Keywords: design
Posted-Date: 14 Nov 2000 13:10:00 EST

DoDi corrected an error in my previous posting:
> IMO "Let" was not optional in the very first Basic implementations, it
> acted as one of the legal begin-of-statement tokens. Later this
> definition was relaxed, so that an identifier would definitely begin
> an assignment statement.
The moderator added:
> [That's correct, Dartmouth Basic required the LET. That's one of the
> reasons the compiler was so fast -- the first token always told it what
> kind of statement it was. -John]


My apologies for the error. If the 1st token of every rule is unique,
it is easy to show that the grammar is LL(1). It also makes
implementing a fast recursive descent parser trivial.


Modern dialects that have made end-of-lines and line numbers optional
in BASIC are relatively far removed from the original implementation
and all include the relaxation.


However, my point was that with the relaxed definition, it is still
possible to eliminate the end-of-lines and line numbers from BASIC and
still have an unambiguous language--it just takes more look-ahead.
The resulting language is no longer LL(1), but it can still be parsed
deterministically.


There is even an LR(1) grammar for such dialects, but not one that you
would want to attach semantics to as some of the statement boundaries
get erased and have to be recovered after parsing ahead. It is much
better to simply process the new dialects with more lookahead.


Finally, as long as end-of-lines and line-numbers are required in
BASIC (and you keep the other statement starters as reserved words),
relaxing the "let" rule still results in an LL(1) grammar. The only
statement that can have a variable name after the line number is a LET
statement.


Thus, it is nor surprising that one of the early changes to the BASIC
language was making the LET keyword optional. I'm certain the
original designers never thought about BASIC as anything other than a
line-oriented language.


Therein lies a typical rub in language design. Relaxing just one minor
restriction on the language's grammar is not usually sufficient to
make the language harder to parse. However, as different restrictions
are eliminated the language can suddenly jump from easy to parse to
ambiguous. Thus, as a language designer, the more restrictions you
relax early on, the harder it will be to relax other restrictions
later.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)


Post a followup to this message

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