Re: Programming language and IDE design

From	hu47121@usenet.kitty.sub.org (Hannah)
Newsgroups	comp.compilers
Subject	Re: Programming language and IDE design
Date	2014-03-02 00:03 +0000
Organization	The Pond
Message-ID	<14-03-003@comp.compilers> (permalink)
References	<13-11-016@comp.compilers> <13-11-018@comp.compilers>

Show all headers | View raw

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.

Thread

Re: Programming language and IDE design Martin Ward <martin@gkc.org.uk> - 2013-11-16 15:55 +0000
  Re: Programming language and IDE design Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-11-16 19:48 +0100
  Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2013-11-18 19:02 -0500
    Re: Programming language and IDE design "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2013-11-19 15:36 +0000
    Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2013-11-19 12:41 -0500
      Re: Parsing Fortran, was Programming language and IDE design glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-19 20:18 +0000
        Re: Parsing Fortran, was Programming language and IDE design glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-21 21:22 +0000
    Re: Programming language and IDE design wclodius@earthlink.net (William Clodius) - 2013-11-22 18:27 -0700
    Re: Programming language and IDE design "robin" <robin51@dodo.com.au> - 2013-11-25 10:33 +1100
      Re: Programming language and IDE design Martin Ward <martin@gkc.org.uk> - 2013-12-03 15:15 +0000
        Re: Programming language and IDE design Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-12-05 03:35 +0100
    Re: Programming language and IDE design hu47121@usenet.kitty.sub.org (Hannah) - 2014-03-02 00:03 +0000
      Re: LL vs LR, was Programming language and IDE design Ivan Godard <ivan@ootbcomp.com> - 2014-03-01 20:31 -0800
        Re: LL vs LR, was Programming language and IDE design Kaz Kylheku <kaz@kylheku.com> - 2014-03-02 18:41 +0000
      Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2014-03-02 12:21 -0500
  Re: Programming language and IDE design Jonathan Thornburg <jonathan@cobalt.astro.indiana.edu> - 2013-11-19 19:39 +0000

csiph-web