Future of Descent and D Eclipse IDE

[Lutger]

Bruno Medeiros wrote:

> On 05/06/2010 09:17, Lutger wrote:
>> Bruno Medeiros wrote:
>>
>>> On 25/05/2010 14:06, Jacob Carlborg wrote:
>>>> On 2010-05-25 04.15, Ary Borenszweig wrote:
>>>>> On 05/24/2010 08:38 AM, Bruno Medeiros wrote:
>>>>>> Hi.
>>>>>>
>>>>>> I'm now in a position where I can dedicate a lot of free time for an
>>>>>> open source project, and I'm seriously considering going back working
>>>>>> on the D Eclipse IDE project. I worked on Mmrnmhrm a couple of years
>>>>>> ago, as part of my thesis, which led to some restrictions on the
>>>>>> kinds of tasks I should work on. Now I don't have that issue, I have
>>>>>> (almost) complete freedom on what I can work on, and in particular I
>>>>>> would like to unify the two current efforts for a D Eclipse IDE:
>>>>>> Descent and Mmrnmhrm, as there is a lot of work being put into both
>>>>>> (especially Descent ^^ )
>>>>>>
>>>>>> Now, Ary has been inactive for quite a while, and he said he wasn't
>>>>>> interested in working in Descent any more :(
>>>>>
>>>>> I know I told you that, but now that I think of it, it's not that I'm
>>>>> not interested. The project has grown too big and in the last releases
>>>>> I added nice features without thinking much about the design and the
>>>>> flexibility of growth... so now I feel the project is kind of a mess
>>>>> and it's very hard to continue it. The problems I see are:
>>>>>
>>>>> * Porting DMD source to Java was done manually and it's a very boring
>>>>> and long task, and we need to find a way to automate it if we'd like
>>>>> to support really good integration with the language (I mean, real
>>>>> semantic value, and because D is not dynamic I think this is worth
>>>>> it).
>>>>
>>>> I have two suggestions for this problem:
>>>>
>>>> 1. Could DMD be compiled to a dynamic library and then be used like a
>>>> plugin, using JNI to interact between the compiler and the plugin.
>>>>
>>>
>>> Nope, the compiler generates a big structure, an AST, which is composed
>>> of nodes from a complex hierarchy of classes. Transferring such
>>> sctructure across JNI would be incredibly hard do implement, not to
>>> mention probably inefficient. JNI (as with most any C interfacing) is
>>> good mostly just for calling C methods with simple parameters.
>>>
>>> The other option would be for the compiler to expose just a thin API
>>> (without big data structures), and have the IDE query the semantic
>>> functionality directly to the compiler. But then the frontend itself
>>> would have to be extended a lot, which would me a lot of complicated
>>> coding in C... argh, no way...
>>>
>>
>> Is working with ddmd an option?
> 
> Nah. Since DDMD is a direct port of DMD, the situation would not be much
> different: you would have a lot of C-like code in D, as well as a
> Walter-like design :P, and you wouldn't be able to change either of
> those things, because then you would make it significantly hard (if not
> impractical) to update the DDMD port with new DMD changes.
> That's exactly the same problem there is with the Java port of DMD.
> 
> I'm now pretty sure the only good long-term strategy is to have a
> compiler/engine designed from scratch to work with IDE functionality.
> Although I didnt realize until now, thanks to your comment, that it
> might be feasible for this engine to be separate, (either as a process,
> or as library), from the Java IDE, and thus the engine could be in a
> different language than Java.
> Hum, this is quite interesting, one very big reason being that then it
> could be reused by different D IDEs, or other sorts of projects...
> 

That, and being written in D, would make it more attractive. There is another option with a headstart: dil, if gpl is not a problem.