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