[Lazarus] WriteLn back to the GUI

[ListMember]

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 
directive block.

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 
bitter end.

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, 
>> IMO.
> 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 
> then?

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? ;)