Re: Programming language and IDE design

George Neuner <gneuner2@comcast.net> wrote:
>On Sat, 16 Nov 2013 15:55:10 +0000, Martin Ward <martin@gkc.org.uk>
>wrote:


>>On Friday 08 Nov 2013 at 21:04, George Neuner <gneuner2@comcast.net> wrote:


>>> The majority of successful languages are LL(k) for small k. It's hard
>>> to get much simpler than that for parsing.


>>C is not LL(K), neither is COBOL, nor C++, nor I think is Java.
>>That probably covers the majority of successful languages:
>>if "success" is defined as "total lines of code in production".


>They _all_ are LL(k). More specifically, I believe all of your
>examples are, at most, LL(2).


I don't think C++ is LL(2).


Think e.g.


    T(a)++;
vs.
    T(a)[5];


(Example from n3485, page 131).


The former is a statement, while the latter is a declaration, and you
can decide this only very late. As the first four tokens are the same,
C++ can't be LL(4), at least.


As you can substitute '('^n x ')' ^n for a in this example (i.e. enclose
that identifier in any number of parentheses), C++ isn't LL(n) for any n.
(In the first case, "a" is a subexpression, that can be parenthesized,
while in the second case, it's the declarator-id that can also be
parenthesized).


Then, in C99, in function parameter declarations
(i.e. parameter-type-list, then in the single parameter-declaration,
after declaration-specifiers, even if you left-factor those), you have
to decide whether you're to descend into declarator or into
abstract-declarator_opt.


FIRST_k(declarator), however, includes "("^k, as does
FIRST_k(abstract-declarator_opt):


The former via k recursions of declarator -> direct-declarator -> ( declarator )
the latter via k recursions of
    abstract-declarator -> direct-abstract-declarator -> ( abstract-declarator )


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.

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