Re: Why are ambiguous grammars usually a bad idea? Why are languages usually defined and implemented with ambiguous grammars?

(snip about conflicts in grammars)
(then I wrote)
> As far as I know, the main cause of ambiguous grammar in programming languages
> is the nested if-then-optional-else structure. If you require else, then it isn't ambiguous,
> but people like the optional else. That usually comes out as a shift-reduce conflict,
> and parser generators know how to handle that.


(snip)


> But you already have the reply from John Levine ...
> [See previous message, where we fixed that with "fi" in 1968. -John]


I first learned if-then-else from PL/I, where it was designed in
about 1963. I now suspect that people get used to the one they
learned first, and find it more obvious.


There is also some language, and I forget now which, with an ELIF
construct, such that you can make a nested if-then-else sequence
without the increase of nesting level, and so need only one ENDIF.


IF e THEN s; ELIF e THEN s; ELIF e THEN s; ENDIF;


(No comment on my preference for ENDIF vs. FI.)


[That would also be Algol 68, using "fi"
It didn't need the semicolons because they are separators,
not terminators as in PL/I and C.
If you've written scripts in the Bourne shell or its descendants
such as bash and zsh, it deliberately looks a lot like Algol 68.
A request from your moderator: if anyone is planning another round
in the semicolon terminator vs. separator war, please don't.
-John]

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