Adem schrieb:
1) In the fpc-devel I have read quite a few arguments that FPC is
production quality and no significant changes can be afforded to that code.
This should have been stated much earlier, before I ever started to
think about refactoring the compiler :-(
While I sympathize with what that implies, it also means that,
structurally, FPC is more or less frozen --except for very small
incremental alterations, there isn't much that can be done with/to it.
That brings me to this remark by DoDi: "Unfortunately some restrictions
apply to the possible changes to the original code, when we want to stay
in sync with the SVN trunk."
I am not at all sure that this is the way to go about it. It is very
likely that the needed changes will soon amount to a shape that will
make it impossible to stay in sync with the FPC trunk.
Since parts of the compiler already are OO, it may be no problem to
replace the implemenations of entire classes, provided that their
functionality is documented - see the thread about the hash tables.
Syncing problems arise for the code that implements the interaction, or
higher-level use of the base classes, where the dependencies and order
of method calls is quite obscure in many cases, and must follow the
original code perfectly.
So, I think it would be more sensible/rational to remove this
artificial/unsustainable restriction/desire and decide to call this a
proper fork for a new version which may or may not be source-mergeable
with the FPC trunk.
I want to preserve those parts of the code, that may be subject to
further trunk evolution, as kind of an (external) library - with a
somewhat strange looking implementation.
Herefore I'll try to leave those obscure pieces of code in place, i.e.
in the original units, and only insert additional procedure declarations
around the identified functional code blocks (procedure header, begin
... end;). Most such procedures will become methods, so that the local
variables of the original code can become class/object members, and no
further declarations or changes to the separated code have to be
inserted into the original code. Other parts of the code, which become
unused (old procedure declarations...), can survive as comments, so that
SVN or Git has good chances to merge any updates from the FPC trunk.
2) As it is, FPC codebase represents a very high barrier of entry for
the uninitiated, drastically reducing any chances of outsiders coming in
and contributing.
To help with that, I'd like to see the new FPC to be functionally as
modularized as possible with sufficiently clear boundaries between each
so that people can work on parts without having to know and worry about
the whole thing all the time.
+1
I can hear the 'speed arguments' (that, doing this would lower the speed
of compilation etc.) but I am yet to be convinced; plus, if I had to
choose between sacrificing a few percent on raw performance and the ease
of maintainability, I'll always go for the ease of maintainability.
+1
I'm not sure about the speed impact of refactoring - the result may
become even faster, by optimization at an higher abstraction level. In
the non-production fork we also can drop certain requirements, that only
apply to small machines (little RAM, no caches...). According changes
may prevent the immediate use of this compiler version on such small
machines, but that's acceptable since cross-compilation still can be
used for such cases.
3) Alternative parsers. I have read all the objections about this. Yes,
it may not solve every single problem. Yes, it will not mean FPC will
take over GCC. Yes, not everyone need this functionality. Etc. Etc.
But, all these seem to ignore one simple fact: Object Pascal (OP) is not
a widely used language. A lot of code that is out there is in some other
language. Which means, OP developers have either to reinvent most wheels
by rewriting the code they need (even though it is readily available in
some other language) or try to convert that code into OP.
I'm not sure about the real-life use of such mixed-language code. When
parts of the code require knowledge of other languages, and is not
understood by the mainstream coder, such unreadable code could reside in
(external, binary) modules as well. Nonetheless it's desireable, for the
sake of integration, that such code is compiled for compatibility with
the FPC environment (RTL...), so that it can be linked into any OPL
application, package or library.
All this is not only a major waste of time, sometimes it requires
extensive knowledge of that language.
So, IMO, anything that helps using that large amount of code base can
only be GOOD THING even if it isn't perfect all the time.
This was the goal of my ToPas project, that converted C code into
Pascal, at source code level. Adding FPC, as an full fledged compiler,
will simply eliminate the need for such a code transformation, with all
known restrictions, and instead will perform the conversion in an lower
level, at its intermediate (compiler internal) representation.
DoDi
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
