Re: Suggestion for dynamic grammar/parser - pls advise

Chris F Clark <cfc@shell01.TheWorld.com>
29 Mar 2007 23:08:50 -0400

          From comp.compilers

Related articles
Suggestion for dynamic grammar/parser - pls advise jsassojr@nospam.com (John Sasso) (2007-03-29)
Re: Suggestion for dynamic grammar/parser - pls advise mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2007-03-29)
Re: Suggestion for dynamic grammar/parser - pls advise DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-03-29)
Re: Suggestion for dynamic grammar/parser - pls advise cfc@shell01.TheWorld.com (Chris F Clark) (2007-03-29)
Re: Suggestion for dynamic grammar/parser - pls advise mefrill@yandex.ru (mefrill) (2007-03-30)
Re: Suggestion for dynamic grammar/parser - pls advise nicola.musatti@gmail.com (Nicola Musatti) (2007-03-30)
Re: Suggestion for dynamic grammar/parser - pls advise jsassojr@nycap.rr.com (John Sasso) (2007-03-30)
Re: Suggestion for dynamic grammar/parser - pls advise jsassojr@nycap.rr.com (John Sasso) (2007-03-30)
Re: Suggestion for dynamic grammar/parser - pls advise DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-01)
Re: Suggestion for dynamic grammar/parser - pls advise Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2007-04-01)
[1 later articles]
| List of all articles for this month |
From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 29 Mar 2007 23:08:50 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 07-03-106
Keywords: parse
Posted-Date: 29 Mar 2007 23:08:50 EDT

John Sasso <jsassojr@nospam.com> writes:


> I have a question regarding implementing a proper dynamic
> grammar/parsing scheme for a parser which is scalable such that it can
> easily be extended to recognize new versions of a language, as well as
> be able to recognize whether a program written in a specific version
> of a language is recognizable by the grammar specific to the
> particular version of the language. I'll try and clarify with a
> simple example below.


Some parts of this problem are hard (e.g. tokens that change on the
character level) and don't have canned solutions to my knowledge.
However, other parts aren't too bad.


1) If you use a table driven parser and have the ability to generate
      and read in new tables, then you have the basic mechanism you need.
      It's not so easy with recursive-descent parsers, unless you
      "interpret" (rather than compile) them. Table driven parsers are
      naturally interpreted.


Note, from what I understand, the GOLD parser generator specifically
focusses on that feature, parser tables that can be written out/read
in. We had a similar feature in the 1.x versions of Yacc++, but
dropped it when we went for more idiomatic C++ in 2.x, where each
output product is one .h file and one .C file. The files containing
the tables to be interpreted did not fit naturally in that scheme and
instead got folded into the .C file, although it would not be
difficult to re-divorce them, just no one has asked for that feature.


2) One way to handle the language variation problems is to use
      inheritance. To me, one of the grate innovations in OO
      programming, was enabling the use of inheritance, which allows one
      to build hierarchies, where A is like B except for the following
      differences....


Yacc++ supports grammar inheritance and so do other tools, e.g. ANTLR.


3) At run-time, you might want a more flexible input format, such as
      GLR parsing or PEGs. PEGs in particular, allow you to order the
      rules (like syntactic predicates do). That my useful in solving
      your try this format, if not that, try this other format
      problem. Note, most PEGs are essentially interpreted (table driven)
      recursive descent with implicit predicates, so that might be near
      the optimal solution, if you can find one that writes out/reads in
      the tables.


Just my opinions,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)


Post a followup to this message

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