|Re: Programming language and IDE design firstname.lastname@example.org (Martin Ward) (2013-11-16)|
|Re: Programming language and IDE design email@example.com (George Neuner) (2013-11-18)|
|Re: Programming language and IDE design firstname.lastname@example.org (2014-03-02)|
|Re: LL vs LR, was Programming language and IDE design email@example.com (Ivan Godard) (2014-03-01)|
|Re: LL vs LR, was Programming language and IDE design firstname.lastname@example.org (Kaz Kylheku) (2014-03-02)|
|From:||Ivan Godard <email@example.com>|
|Date:||Sat, 01 Mar 2014 20:31:45 -0800|
|Organization:||A noiseless patient Spider|
|References:||13-11-016 13-11-018 14-03-003|
|Posted-Date:||02 Mar 2014 10:11:33 EST|
On 3/1/2014 4:03 PM, Hannah wrote:
> 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.
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
Search the comp.compilers archives again.