[Lazarus] Using FPC parser/tokenizer for code formatting
KrisztiƔn Nagy
nkrisztian89 at gmail.com
Mon May 31 16:21:27 CEST 2010
Hi lazarus list,
At the beginning of this discussion I also wondered if one should make a
"general purpuse" parser out of the compiler's one, but now I think one
should not.
Compiling and code formatting are different tasks. Both need to parse the
code but if you want an optimized solution then the parsing has different
characteristics in the two tasks.
These are better to be done by different parsers, the one thing that should
be common is a clear specification of the language syntax (now it is called
reference guide), highlighting the differences between versions. If we have
a good (well designed) general purpuse parser then in case a new version is
released it requires minimal effort to adopt new syntax (the sources may not
even need to be changed just the used language description files) with the
help of the specification. This parser can be used to different purposes
(code formatting, translating, documentation, UML round-trip) and can have
many features the compiler's parser doesn't need to have.
I don't see this as a bad thing.
I think the most important points are:
- have 1 such ('canonized') parser, not many different projects, and make
projects in need of a pascal parser use this one
- it must be well designed to be easy to keep up-to-date (follow changes in
syntax)
- be well documented to be easy to maintain
(the last two are just trivial software engineering principles)
I don't think we should base this parser on the compiler's one, as some have
already pointed out, there are other parsers out there more close to a
general purpose one. Using one of those (fcl-passrc or codetools' parser)
and developing it to meet the above requirements seem to me the most clear
solution that also requires the least effort.
"You'll have competing products one pulling one way, the other pulling
another."
I'm not sure I understand you correctly. If you were talking about the two
parsers then this makes no sense to me as we are going to have two parsers
both sticking to the same "official" free pascal specification, one
optimized for high speed compilation the other for general purpose use.
These are not competing products and even less pulling each other different
ways.
regards
KrisztiƔn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20100531/57cd3ca3/attachment-0004.html>
More information about the Lazarus
mailing list