Future of Descent and D Eclipse IDE

[Bruno Medeiros]

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


-- 
Bruno Medeiros - Software Engineer