[Lazarus] WriteLn back to the GUI
listmember at letterboxes.org
Fri Oct 25 12:51:36 CEST 2013
On 2013-10-25 10:53, Sven Barth wrote:
> Am 25.10.2013 01:06, schrieb ListMember:
>> One of my aims (one which we discussed here a few years ago) is to
>> rip the parser and lexer from the compiler. I want to have a token
>> tree (including directives) from the mouth of the horse (so to speak).
> That will be quite complicated, because the scanner will not output
> the directives it parsed (e.g. if you do a "consume(_SEMICOLON)" to
> parse a ";" any directive between your current position and the next
> ";" will be handled and the parser will not be notified of any changes
> (as a result of these directives there might be changes in settings
> variables or defines however).
Unless there's a lot more deeper magic than I can fathom, I am guessing
the parser is parsing the directives if only to ignore code in that
If this is so (is it?), can't I inject/override some code in there to
emit a token for the directive as well as make it also parse the blocks
it normally would ignore?
> Also the tree is not really possible to get a hold of, because a node
> (e.g. a fornode for a for-in) might be immediately replaced by a
> whilenode thus you'll never see that there was a for-in.
So, I will need to catch things before they get optimized/transformed
into something else.. I love these tricks/traps.. :)
> Additionally the parser is not geared towards handling erratic code.
> There are quite some places where error recovery is tried so that
> errors further down can be displayed, but in essence the parser is
> very bad in handling erratic code.
Frankly, I too am not interested in uncompilable code; so I won't mind
if it throws in the towel before attempting to scan everything until the
But, yes, all these shortcuts/pitfalls (for what I want to do) are quite
discouraging, yet the flip-side means any alternative independent of FPC
will always be lacking.
>> I also want to see how hard it is to turn the compiler into a module
>> of the frontend (see my text mode hatred) by getting rid of
>> commandline switches (and also of textmode feedback).
> Here I'd suggest you to look at the code of the text mode IDE again.
> It compiles the compiler itself and passes its own options set in the
> FreeVision TUI to the compiler.
Thank you. I am hoping I will get to that in good time.
>> Actually, I am surprised that no one (that I know of) has done this yet.
> The text mode IDE is doing it...
I meant the GUI ones.
>> After all, both FPC and all the IDEs (Lazarus, fpGUI, MSEide+MSEgui
>> etc.) use FPC but the degree of integration between them is lacking,
> Because by the way it currently is you can easily switch the compiler
> version and the compiler target. Each compiled compiler can only
> compile for one architecture (but each supported OS of that
> architecture), so how would you implement cross platform compilation
Couldn't it be done through DLLs?
I mean, compile the compiler into a dll where the name is an easily
format that tells (say) Lazarus what version it is, and its native and
target platforms are.
At that point, it would need a stable (yet an extendable) API, but it
seems it is doable.
[This, if it works, does not preclude a standalone compiler; a shim-like
exe simply uses one of those DLLs.]
Or, have I just reinforced the assertion that ignorance is bliss? ;)
More information about the Lazarus