[fpc-devel] Alternative parsers

[Hans-Peter Diettrich]

Florian Klaempfl schrieb:
> 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?

That's what deserves documentation.


>>> 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.

For good reason: a clear interface between the parser syntax and 
semantic. That interface finally can be located in the most appropriate 
location, e.g. tprocinfo for procedure attributes, tparamanager for 
parameters. I kept it separate for now, in order to keep the 
modifications to the existing units at a minimum.


>>> 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.

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.

I did some reformatting on the extracted semantic code, for analysis 
purposes. This code will become part of the new interface later, so that 
it will be moved in any case.


All in all I understand that you mean:
- the project deserves no documentation, SVN history is perfectly 
sufficient for that purpose
- since nobody knows how all the many pieces fit together, only really 
necessary punctual changes are allowed
- changes should be restricted to code removal, everything else might 
decrease compilation speed
- parallel execution is not necessary and never will be implemented, 
because it would cause too many changes to the existing code
- the existing code deserves no restructuring
- leading whitespace is an essential part of the code

So there's left nothing what I could do for FPC.

DoDi