Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site nbires.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!nbires!rcd
From: rcd@nbires.UUCP (Dick Dunn)
Newsgroups: net.lang
Subject: Re: Varieties of conditional statement (parsing "if")
Message-ID: <133@nbires.UUCP>
Date: Tue, 15-Oct-85 05:25:14 EDT
Article-I.D.: nbires.133
Posted: Tue Oct 15 05:25:14 1985
Date-Received: Sat, 19-Oct-85 03:56:51 EDT
References: <964@vax2.fluke.UUCP>
Organization: NBI,Inc, Boulder CO
Lines: 23

Without entering the general fray here, there's one matter which needs to
be corrected on parsing:
> There are other arguments.  For instance, the Pascal style if statement is
> well known to result in ambiguities in the construction of reasonable
> parsers.  (I believe there is a grossly complex mechanism that can be
> applied to disambiguate the if statement; see SIMULA BEGIN by Birtwistle et.
> al.)  One could argue on this basis that such languages are syntactically
> weak, and thus that Ada style conditional constructs are superior.

Ambiguities exist as language attributes, quite independently of the
construction of parsers.  The "Pascal style" if has existed at least since
Algol 60.  Any reasonable mechanism for constructing parsers must be able
to deal with it.  No grossly complex mechanism is required.  Rather, in a
hand-coded parser the ambiguity is resolved by the only natural choice in
the code for the parser.  In LR parsers, the solution is to indicate which
action is to be taken in the event of a shift-reduce conflict.  In LL
parsers, the solution is to indicate which alternative is assumed in the
event of a director-set overlap.  Very little complexity is added to the
parser-generation system.  No complexity is added to the generated parser
itself.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Simpler is better.