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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
