[Lazarus] Using FPC parser/tokenizer for code formatting

Mattias Gärtner nc-gaertnma at netcologne.de
Mon May 31 17:56:40 CEST 2010


Zitat von Adem <listmember at letterboxes.org>:

> On 2010-05-31 16:00, Mattias Gärtner wrote:
>> Zitat von Adem <listmember at letterboxes.org>:
>>
>>> [...]
>>> How would *you* deal with macros?
>> I would not use a complete parser.
>> I would use a forgiving parser like the synedit highlighter or the  
>> indentation parser of the codetools.
> Why is this emphasis on the parser being '/forgiving/'?
>
> Why wouldn't I want to know about the ugly truth that the code I  
> just wrote will not compile?
>
> Why should I have to wait till I compile the rubbish I produced to  
> find out that it is indeed worthless?

Why should I fix all required source files to format one selection?
IMHO a code formatter should not be as picky as a compiler and allow  
to format code even if it does not compile (e.g. because it is code  
for another target OS).

And I guess, even if the formatter uses the compiler parser, it will  
still lack behind. Every time the compiler parser is extended the  
formatter needs to be updated. I doubt that the compiler crew will  
maintain the formatter, so the formatter will be broken often (and  
probably often without noticing).
Using the fcl parser will at least give you helpful entries in the svn  
log solely about the parser.

My conclusion:
Using the compiler parser will limit the code formatter to compilable  
sources, increases maintenance cost, bites the goal of a fast  
compiler, and hardly allows to format fragments. Using the fcl parser  
will be easier and allows to create a more comfortable formatter.
Or do it like the codetools and write several different parsers for  
the different goals.


Mattias






More information about the Lazarus mailing list