[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