dmd support for IDEs

[Yigal Chripun]

On 11/10/2009 15:23, Ary Borenszweig wrote:
> Walter Bright wrote:
>> In my discussions with companies about adopting D, the major barrier
>> that comes up over and over isn't Tango vs Phobos, dmd being GPL,
>> debugger support, libraries, bugs, etc., although those are important.
>>
>> It's the IDE.
>>
>> So, while I'm not going to be writing an IDE, I figure that dmd can
>> help. dmd already puts out .doc and .di files. How about putting out
>> an xml file giving all the information needed for an IDE to implement
>> autocompletion? There'd be one .xml file generated per .d source file.
>>
>> What do you think?
>
> What I think is that even with an xml representing the parse tree (maybe
> with some semantic stuff resolved) it'll be still incomplete for a real
> IDE (the kind of thing users expect from an IDE). You can see this
> video, for example:
>
> http://www.youtube.com/watch?v=KQbTT605ags
>
> So you have:
>
> ---
> module one;
>
> class Foo(T) {
> static if (is(T == class)) {
> T property;
> } else {
> T someMethod() { return T.init; }
> }
> mixin(guessWhat!(T)());
> }
> ---
>
> You want to define an xml for that module that'll help IDEs. Can you
> think what it'll look like?
>
> Now the user writes in another module:
>
> class Bar {
> }
>
> void x() {
> auto foo = new Foo!(Bar)();
> foo. <-- what does the IDE do here?
> }
>
> Now, the correct thing for the IDE to do is to suggest the field "Bar
> property". How can the IDE do that just with an xml? It can't. It need
> to perform some kind of semantic anlysis to Foo's argument to see if
> it's a class, match the static if in the template, replace template
> parameters, etc. It also needs to evaluate the string mixin.
>
> Of course you could say "Bah, just show all the declarations inside the
> template in the autocomplete", but that's wrong. That'll lead to files
> that don't compile. You could ommit supporting autocompletion or other
> nice features, but that's exactly the big features of D. If you don't
> support that then it's like using Java or C# from within the IDE: you
> could use the advanced features but the IDE won't help you. And in your
> discussions with companies adopting D, I'm sure they were talking about
> great IDEs like JDT Eclipse or Visual Studio, not just some tool that
> helps you a little but not anymore when things get interesting.
>
> Oh, and you need to have some kind of semantic analysis to know the type
> of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
> Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
>
> auto b = foo.property;
> b. <-- and here?
> // remember "property" is templated and depends on static analysis
> // or the IDE could need to resolve alias this or other things
>
> So... my opinion (like some others, I see) is to either ask things to
> the compiler directly (but here the compiler lacks some info, like exact
> source range positions), or to have a compiler (not a full-blown one,
> just the front-end) built into the IDE, and that's what Descent is.
> Unfortunately Descent is sometimes slow, sometimes buggy, but that's
> normal: just a few people develop and maintain it (so I can see a
> similarity with dmd here, where each day I see two or three new bugs
> reported). If more people were into it, more unit tests were written
> into it and, most of all, more people would use it, it'll get better.
>
> Another problem that people see in Descent (maybe also JDT Eclipse and
> Visual Studio0 is that it's huge, it consumes a lot of memory and they
> don't want to open a huge tool just to hack some lines. My answer is:
> memory performance can be improved (but not a lot), but since an IDE is
> a huge tool it requires a lof from the computer. And an IDE is not meant
> to be used to hack some lines, it's meant to help you write big project,
> huge projects without getting lost in the amount of code.
>
> So my bet would be to start supporting an existing IDE that integrates a
> compiler into it. Updating it is easy: just port the diffs between DMD
> versions. It's a huge job for one or two people, but if a lot of people
> were involved it's not that much. Of course I'd recommend you to try
> Descent since I'm one of it's creators and I do believe it can get
> pretty good. :-)

well put.

btw, given that we have a port of SWT for D, how hard would it be to 
create our own native D version of eclipse?