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) |
[2 later articles] |
From: | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
Newsgroups: | comp.compilers |
Date: | 29 Mar 2007 23:08:06 -0400 |
Organization: | Compilers Central |
References: | 07-03-106 |
Keywords: | parse |
Posted-Date: | 29 Mar 2007 23:08:06 EDT |
John Sasso wrote:
> The grammars are such that grammar
> G_k+1 (for language L_k+1) is like G_k except new productions and
> terminals (and, of course, non-terminals) are added in order to
> recognize new features in version k+1 of the language that are not
> present in grammar G_k of L_k.
Why would you need different grammars, when the parser of the most
derived language will accept the other languages as well? This would
be required only when the languages form an tree, with incompatible
extensions in e.g. the G_k_1 and G_k_2 branches.
If the purpose is the rejection of something like non-ANSI extension to
a language, I'd assign version number attributes to the added rules.
Then one can determine, during the application of a rule, whether it is
part of the given language version. Or one can determine, after an
parse, what's the minimal required language version, from the maximum of
the processed rule version numbers.
> I would like to develop a parser which is scalable and flexible such that:
>
> 1. When a new version of the language becomes available, the parser can
> be easily extended to recognize a program written in the new language
> w/o a lot of time-consuming rework.
Doesn't this mean that you'll have to establish the guidelines or
restrictions, that will apply to such extensions?
Extending a grammar requires knowledge of the meta language, and of how
to deal with errors detected by the parser generator. There exists no
way to "easily" extend a grammar, unless errors can not occur at all ;-)
> *** Assume someone else, not I, creates new versions of the language.
This might result in a language tree, with different extensions inserted
by multiple people. If nobody has to care about the extensions, added by
other people, everybody can maintain his own (flat) language branch.
> 2. If the input to the parser is a program written in L_k, and the
> version of the language the program was written in (i.e. k), then the
> parser will parse the program based on grammar G_k.
This is where I'd tell the parser to treat expansions of rules above
level k as syntax errors. The restriction will have to be encoded in the
semantical part of the grammar.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.