[fpc-devel] Alternative parsers
Florian Klaempfl
florian at freepascal.org
Mon Oct 18 13:50:53 CEST 2010
Am 18.10.2010 14:01, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
>>> One goal of this refactoring is the determination and documentation of
>>> the actions, required in certain pieces of the grammar.
>>
>> Why should we need these actions?
>
> Yes, that's one of the big questions. What is that funny call to XYZ
> good for, in this particular place? What has to be changed, when a new
> attribute is introduced? etc...
And?
>
>> I still don't see a need to get the parser more robust, if it's possible
>> at all. The front end including the parser is one of the simplest,
>> robust and stable parts of the compiler.
>
> You seem to have missed that the parser itself is unchanged - only the
> connection to the related data structures (symbol tables...) is sorted out.
... which that makes things really hard to overlook: code spread over
multiple locations for nothing.
>
>
>> With all the drawbacks like:
>> - people knowing the old code for 15 years having to dig into new code
>
> never change a running program? ;-)
Yes. The current parser fulfills its purpose perfectly. FPC doesn't need
multiple parser or whatever.
>
>> - slower
>
> how much?
Even if it small, multiple small changes add up.
>
>> - code spread over multiple locations
>
> yes, the existing code could be concentrated into less units.
No, I wrote locations, see above.
>
>> - lost svn blame history
>
> not necessarily.
You reformatted and moved a lot of code, so a lot of it is lost.
>
>> - last but not least, you coding style does not follow the compiler code
>> style
>
> that is?
See existing code and http://wiki.freepascal.org/Coding_style and you
should also know that it is changed because you re-formatted code.
More information about the fpc-devel
mailing list