One more question - an untapped audience.

[Bruno Medeiros]

On 12/02/2014 13:35, Daniel Murphy wrote:
> "Bruno Medeiros"  wrote in message news:ldfpa7$27s3$1 at 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?