[Lazarus] Parser

[Hans-Peter Diettrich]

Florian Klämpfl schrieb:

>> 3) The compiler builds an parse tree for every procedure, but I found no
>> way yet to make this tree accessible. 
> 
> It is no parse tree but some intermediate represensation.

Yes, it's an AST, but I didn't want to put too much into the 
advertisement ;-)

>> There should exist a
>> method/procedure in the CPU specific code, that is called to create the
>> binary code for a procedure, but I could not yet locate it.
> 
> psub.pas: tcgprocinfo.generate_code, it is generic.

I couldn't find out how the code generator is involved. Most methods are 
non-virtual...


>> 4) It's not yet known how the rest of a unit (declarations...) is
>> represented internally.
> 
> It is processed directly.

This means that the parser must be patched.


>> In detail the last item [5] suggests an more flexible parser, that can
>> do with the scanned tokens whatever is appropriate in the scope of a
>> specific application. The general solution is a separation of the
>> syntactical and semantical procedures in the parser. For fastest
>> processing the semantical code can be made selectable just as for the
>> CPU, by placing this code into a dedicated directory. I hope that this
>> solution is acceptable to the FPC maintainers, and I'm willing to
>> refactor all the parser units accordingly.
> 
> I see two problems:
> - speed

Not really. The semantic actions are so complex, that another call (to 
them) should not matter.

> - reduced readability of the parser code because the code for handling
> something will be spread over different locations resulting also in
> reduced maintainability: just look at the code generator code, to
> support different architectures fpc the code generator is split at
> several levels making it very hard to get an overview on it and even
> more get into it.

Yes and no. A good separation will help to clarify much.


>> One big advantage of the separation into syntactical and semantical
>> parts is the chance for adding further languages to the compiler, 
> 
> Is this really desired? The advantages of fpc are that it is written in
> its native language but its code generator is not sophisticated enough
> so it's imo not worth to add another front end.

We'll see ;-)

DoDi