<p>Am 25.10.2013 12:52 schrieb "ListMember" <<a href="mailto:listmember@letterboxes.org">listmember@letterboxes.org</a>>:<br>
><br>
> On 2013-10-25 10:53, Sven Barth wrote:<br>
>><br>
>> Am 25.10.2013 01:06, schrieb ListMember:<br>
>>><br>
>>> 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).<br>

>><br>
>> 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). <br>

><br>
><br>
> 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.<br>
><br>
> 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?<br>
></p>
<p>No, the parser will never see those. After all that's one purpose of ifdefs: to keep the parser from reading things that is couldn't possibly parse. Directives are completely handled by the scanner.</p>
<p>><br>
>> 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. <br>
><br>
><br>
> So, I will need to catch things before they get optimized/transformed into something else.. I love these tricks/traps.. :)<br>
></p>
<p>This often happens inside the typecheck passes whereby the following code might do things dependant on that result.</p>
<p>> 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.<br>
></p>
<p>In my opinion that energy is better put into getting e.g. fcl-passrc up to date and keep it that way (so that at least each release can handle code that the compiler also accepts).</p>
<p>>>> 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.<br>
>><br>
>> 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?<br>

><br>
><br>
> Couldn't it be done through DLLs?<br>
><br>
> 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.<br>
><br>
> At that point, it would need a stable (yet an extendable) API, but it seems it is doable.<br>
><br>
> [This, if it works, does not preclude a standalone compiler; a shim-like exe simply uses one of those DLLs.]<br>
><br>
> Or, have I just reinforced the assertion that ignorance is bliss? ;)</p>
<p>I already had the idea with DLLs once myself. <br>
As long as the interface for exchanging options (and maybe also unit locations ;) )is kept stable or at least backwards compatible this should work. And as long as the heaps are kept seperate unloading a compiler library should also solve the problem with memory leaks... (maybe add a function to the API to get the current heap state ^^)</p>

<p>Regards,<br>
Sven</p>