Re: LL vs LR, was Programming language and IDE design

On 3/1/2014 4:03 PM, Hannah wrote:
<snip>


> So the C grammar is not LL(k) for any k, either. You can probably parse
> that particular part of the C/C++ grammar easily using LR.
>
> Hannah.


The standard way to handle this, and many such other cases where a
formal grammar is not LL, is to introduce a function (in recursive
descent) or rule (in parser generators) that recognizes "parenthesized
thingy" and then figure it out later. Yes, that amounts to LR, but you
only need it in a few specialized places. There's an equivalent trick
in "DOI=1," in Fortran, where you let the lexer resolve it so the
parser sees proper lexemes, not characters.


C and its descendants are well known for being inhumane (as well as
parser-unfriendly) in their excessive overloading of parens and braces.
More friendly (or less keystroke-obsessed) languages require all
syntactic regions to have both openers and closers, unique for each kind
of region, to avoid the canonical C bug of mismatched closers; Algol68
is an early example of doing it right.
[C++ is unusually bad, with some parts just plain ambiguous. In the example
a few messages back, I gather that the rule is that if you can parse it as a
declaration, it's a declaration, otherwise it's something else. -John]

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