On 12/02/2014 13:35, Daniel Murphy wrote:
"Bruno Medeiros" wrote in message news:ldfpa7$27s3$1...@digitalmars.com...
There is not a chance in hell DMD would sucessfully be adapted for
these purposes. Maybe as fork, but not as the main stream. Even as a
fork I hardly see it happening (The Descent IDE went with this route
but it the semantic engine was buggy and quickly became very hard to
maintain.) The reasons are manyfold and I'm not going into detail, but
suffice to say a semantic engine for an IDE needs to be prepared to
run in an interactive/deamon mode to have a decent performance, not in
batch (run once) mode like a compiler. This adds several constraints
and requirements to the semantic engine architecture, something that
DMD is not prepared to. It would take a large engineering effort to
adapt it to that, and crucially, Walter would have to be involved, but
he has his hands full already.
Well, I need to revise my statements because, upon further thought, I
dont find them entirely accurate.
I was thinking of the use case of making DMD an interactive semantic
engine deamon, which I still think would take a miracle to get there
(whilst at the same time having a decent measure of quality, that is).
But I understand now your idea is different, you just want to expose the
current compiler functionality as a *library*, and let other
users/programs use it as they see fit, correct? A deamon engine could
then be built on top (or the compiler library embedded directly in
IDE/tool code), but that would be a task for someone else.
Now, that goal (compiler as library) I do believe to be feasible, but
still incredible hard (again, if you want to have something of quality
that is). For example, the compiler library functionality needs to be
prepared to be re-used within the same session. This means you need to
do proper memory management, you can't just allocate blindly and assume
its fine because the code is running under a compiler program which will
then terminate once it's run once. From what I've heard some time ago,
DMD code does nearly no memory management. Maybe this has changed in the
meanwhile and the situation improved drastically (or a D port would
bring in the GC and deal with this problem that way - but then we'd need
the D port for that).
There is other minutiae of functionality which is also important (for
example, good parser error recovery, with sensible AST and source ranges
in the result nodes, etc.)
But anyways, those are secondary points actually. What I think is really
crucial, is that we don't have a main-stream compiler in D. When DMD
gets ported to D, and the main development of DMD happens there, in the
D version, then I'll believe a reasonable compiler-as-library could happen.
> I disagree, this is 'the plan'. Please, go into detail, I would love to
> find out about any roadblocks I've overlooked now rather than later.
What do you mean, are you going to invest a lot of work on that?
