|Compiler compiler that supports dynamic keywords? firstname.lastname@example.org (Ramon M. Felciano) (1999-09-10)|
|Re: Compiler compiler that supports dynamic keywords? email@example.com (Chris F Clark) (1999-09-16)|
|Re: Compiler compiler that supports dynamic keywords? firstname.lastname@example.org (Quinn Tyler Jackson) (1999-10-13)|
|From:||"Ramon M. Felciano" <email@example.com>|
|Date:||10 Sep 1999 00:10:14 -0400|
I'm interested in building a parser that dynamically determines the
lexical structure of particular rule element at runtime. For example,
consider the following rule (in JavaCC pseudocode):
The key is that the definition of <nameType1> and <nameType2> needs to
be changeable at runtime. For example, <nameType1> might be words
defined in dictionary A, and <nameType2> be words defined in
dictionary B. Thus this grammar would parse and recognize sentences
where the first word is "Hello" and the second word is in one of those
two dictionaries (I'm willing to guarantee mutual exclusivity of
dictionary membership); all other sentences are rejected. Ideally this
rejection should happen after the (bad) second word is entered.
I'm calling this dynamic keywords because like keywords, the parser
itself rejects any second word that isn't either a <nameType1> or
<nameType2> at parse time. Maybe there's a better phrase for it --
compilers aren't my thing :-). Also, I realize that I'm blurring the
syntax / semantics line a bit (i.e. trying to get the syntactic parser
to do some semantic work for me), but this seems like something common
enough that I'm hoping someone else has solved it before. For example,
I've seen a number of source code editors that do completion on
function names (not language keywords) based on the functions that
have been defined thus far in the source code file. So the compiler
must be dynamically keeping track of possible legal token matches...
Any suggestions for me? We're working in Java but are happy to look at
other languages for this problem.
Ramon M. Felciano
InGenuity Systems, Inc.
Return to the
Search the comp.compilers archives again.