[fpc-devel] Alternative parsers

[Hans-Peter Diettrich]

Florian Klämpfl schrieb:
> Am 17.10.2010 17:45, schrieb Hans-Peter Diettrich:
>> Florian Klämpfl schrieb:
>>> Am 17.10.2010 11:19, schrieb Hans-Peter Diettrich:
>>>> 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. 
>>> I won't merge it and take the burden to be responsible for a broken
>>> compiler for no gain.
>> What should break the compiler, in this approach?
> 
> See e.g. the exit problem from a few days ago how quickly something is
> broken.

This problem showed up immediately, and since the reason is known, it 
can be cured easily (check the semantic code for "exit"...).

I implemented the new parser model in parallel to the old one, so that 
different behaviour can be determined by a (binary) comparison of the 
result of both versions, what can be automated like for the compiler 
bootstrap. The parser units and even single procedures can be refactored 
one by one, unlike in my first approach (OO_parser).

Once a part (procedure) has been tested, it can replace the original 
procedure. All the $ifdefs can be removed in this step, they have been 
introduced only for easy detection of changes to the original (trunk) 
code. The same for the virtual parser methods, which only have been 
introduced to allow for parallel implementations of the very same 
parser. Once the switch to the new code structure has been made, the 
parser procedures can be called immediately, just like before.


One goal of this refactoring is the determination and documentation of 
the actions, required in certain pieces of the grammar. In the first 
step the semantic code simply reflects the actions in the existing code, 
i.e. *how* something is done. In further steps documentation can be 
added, that also reflects *why* things are done in exactly this way, 
possibly reveiling flaws and duplicate (maybe differerent) 
implementation of the essentially same tasks. Such multiple 
implementations can be replaced by unique semantic methods, in a layer 
on top of the basic procedures and methods of the involved classes. The 
result is a more stable compiler, where changes in one part can not 
break the code in other parts any more.

DoDi