Re: object oriented implementations of rec. descent parsers

Thomas Wolff wrote:


> Whenever you want to call a routine of a
> class meant to handle a certain syntactic structure to detect if that
> structure can be recognized for parsing, you need an object of that
> class first - just to be able to call that function!


I believe this problem is caused by lumping the "parser" and "parse
tree node" functionalities into the same set of classes.


I'd separate those into two sets of classes, roughly following the
"abstract factory" pattern: The "parser" classes are singleton classes
whose instances are pre-created before the parsing starts. Each
parser object is invoked in a specific context and either fails,
returning nothing, or succeds, creating and returning a parse tree of
some specific type. (Failure is not necessarily an error, but could
cause the parser driver to try another parser object that is
applicable in the same context.) New (specialized) parse tree node
classes are bound into the system by creating new parser classes and
installing their instances into the tables before parsing starts. The
knowledge of the specific parse tree node classes are encapsulated in
the parser classes.


There are a lot of tradeoffs in way the overall control of the parser
is organized: The parser driver could be table-driven, looking up
applicable parser objects based on state and next token. Parser
classes could be very specialized, only able to create one specific
class of parse tree node, or very broad, in effect, encapsulating
large parts of the decision logic of the recursive descent parser in a
single class.




Anund Lie Tel: +47 22 85 26 27
Norsk Regnesentral/Norwegian Computing Center Fax: +47 22 69 76 00
Postboks 114 Blindern, N-0314 OSLO, NORWAY Internet: Anund.Lie@nr.no
--

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