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? ;)
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
