[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