[fpc-devel] Alternative parsers
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Sun Oct 17 11:19:38 CEST 2010
Hans-Peter Diettrich schrieb:
> Now I started another branch, that is not as "intrusive" as my other
> branches. The AltParser branch makes multiple parsers available, each of
> which sits in its own class derived from TParser.
After some tries I've arrived at a working model. The semantic actions,
implemented in semantic objects of various kinds, are currently
structured according to their occurence in the parser code. In a later
step they should be broken down into logical steps, that better reflect
the *needs* of an parser (registering encountered variables...).
Some parser methods have been virtualized, so that existing code can be
reused. E.g. calls to statement() or expr() are caught in a procedure,
that defers the call to the according virtual method of the current
parser. The original reusable procedures have been renamed, so that all
calls are routed through the parser methods. Inside an parser the
specific procedures can be called directly, bypassing the virtualization.
Now it should be possible to implement a modified OPL syntax, e.g. with
modulaic statement sequences instead of statement blocks, block-local
variables, initialized local variables, statement sequences separated by
commas (C style) and whatever comes into mind. Feel free to implement
your own language, based on your TParser descendant in the AltParser
branch :-)
Further development should be synced better with the trunk. Please let
me know about the chances, that the required hooks are merged into the
trunk. When the semantic code is already separated in the general parser
units, as demonstrated in the cloned p*OPL units, that code could be
maintained in fully reusable semantic objects; these objects can become
part of the existing parser units, so that no clones have to be
maintained further.
DoDi
More information about the fpc-devel
mailing list