April 10, 2012
On 2012-04-10 04:24, Andrei Alexandrescu wrote:
> On 4/9/12 9:21 PM, Ary Manzana wrote:
>> Yes, D definitely needs that. The Eclipse plugin could just use bindings
>> to the D compiler API with JNI.
>
> Would the JSON compiler output help?
>
> Andrei

No, it's no way near sufficient for what Descent can do and what's expected from an IDE these days, think JDT for Eclipse.

Descent can handle:

* Syntax highlighting
* Semantic highlighting
* Show lex, parse and semantic errors
* Compile time debugging
* Compile time view
* Formatting
* Show the actual type of an inferred or aliased type
* Smart autocompletion
* Many other things as well

Note that in addition to (most of) the above, JDT can handle a lot more. The compiler is the only tool that can properly handle this. It's also the only sane approach, to have the compiler usable as a library.

Just take a look how it used to be (and in some cases are) in the C/C++ world before Clang and LLVM came a long:

* You have the compiler
* An IDE with a "parser/compiler"
* The debugger with an (expression) "compiler"

All these "compilers" are different and need to stay in synch. That's not how you do good software development. You build a compiler library that can be used in all the above tools. BTW, it's only the real compiler that can handle everything properly.

-- 
/Jacob Carlborg
April 10, 2012
On 2012-04-10 04:47, Brad Anderson wrote:

> It's already been started.  SDC: https://github.com/bhelyer/SDC

But has it been built to be usable as a library?

-- 
/Jacob Carlborg
April 10, 2012
Am Tue, 10 Apr 2012 08:46:05 +0200
schrieb Jacob Carlborg <doob@me.com>:

> Descent can handle:
> 
> * Syntax highlighting
> * Semantic highlighting
> * Show lex, parse and semantic errors
> * Compile time debugging
> * Compile time view
> * Formatting
> * Show the actual type of an inferred or aliased type
> * Smart autocompletion
> * Many other things as well
> 
> Note that in addition to (most of) the above, JDT can handle a lot more. The compiler is the only tool that can properly handle this. It's also the only sane approach, to have the compiler usable as a library.
> 
> Just take a look how it used to be (and in some cases are) in the C/C++ world before Clang and LLVM came a long:
> 
> * You have the compiler
> * An IDE with a "parser/compiler"
> * The debugger with an (expression) "compiler"
> 
> All these "compilers" are different and need to stay in synch. That's not how you do good software development. You build a compiler library that can be used in all the above tools. BTW, it's only the real compiler that can handle everything properly.

I think you are right. So clearly to make bindings possible this library would export a set of C functions. (I should think of export(C) as the "least common denominator" here.) DMD is no where close to look like a library and IDEs/debuggers need a different set of features. I think we can start a new thread to discuss this and maybe a Wiki page to collect ideas and brainstorm, unless there are better tools for that available. It would be nice if the developers of DDT, Descent, Mono-D and VisualD could share their insights there to get the requirements straight.

-- 
Marco

April 10, 2012
On 2012-04-10 19:49, Marco Leise wrote:

> I think you are right. So clearly to make bindings possible this library would export a set of C functions. (I should think of export(C) as the "least common denominator" here.) DMD is no where close to look like a library and IDEs/debuggers need a different set of features. I think we can start a new thread to discuss this and maybe a Wiki page to collect ideas and brainstorm, unless there are better tools for that available. It would be nice if the developers of DDT, Descent, Mono-D and VisualD could share their insights there to get the requirements straight.
>

Sounds like a good idea.

-- 
/Jacob Carlborg
April 11, 2012
On 4/10/12 2:46 PM, Jacob Carlborg wrote:
> On 2012-04-10 04:24, Andrei Alexandrescu wrote:
>> On 4/9/12 9:21 PM, Ary Manzana wrote:
>>> Yes, D definitely needs that. The Eclipse plugin could just use bindings
>>> to the D compiler API with JNI.
>>
>> Would the JSON compiler output help?
>>
>> Andrei
>
> No, it's no way near sufficient for what Descent can do and what's
> expected from an IDE these days, think JDT for Eclipse.
>
> Descent can handle:
>
> * Syntax highlighting
> * Semantic highlighting
> * Show lex, parse and semantic errors
> * Compile time debugging
> * Compile time view
> * Formatting
> * Show the actual type of an inferred or aliased type
> * Smart autocompletion
> * Many other things as well
>
> Note that in addition to (most of) the above, JDT can handle a lot more.
> The compiler is the only tool that can properly handle this. It's also
> the only sane approach, to have the compiler usable as a library.
>
> Just take a look how it used to be (and in some cases are) in the C/C++
> world before Clang and LLVM came a long:
>
> * You have the compiler
> * An IDE with a "parser/compiler"
> * The debugger with an (expression) "compiler"
>
> All these "compilers" are different and need to stay in synch. That's
> not how you do good software development. You build a compiler library
> that can be used in all the above tools. BTW, it's only the real
> compiler that can handle everything properly.

Yes. In fact, JDT has a built-in Java compiler in their implementation. Maybe it was easier to do it for them because the Java spec is easier and doesn't fluctuate that much as the D spec. And JDT used that compiler all over the place for getting all those IDE features.

April 11, 2012
On 2012-04-11 04:50, Ary Manzana wrote:

> Yes. In fact, JDT has a built-in Java compiler in their implementation.
> Maybe it was easier to do it for them because the Java spec is easier
> and doesn't fluctuate that much as the D spec. And JDT used that
> compiler all over the place for getting all those IDE features.

Exactly. Java hasn't changed much in the last 10 years (ok, just now it starts to changed again). JDT also contains a full compiler, not just the frontend, so it can compile all code. This would be nice to have for D as well but I think the frontend is the most important part.

-- 
/Jacob Carlborg
April 12, 2012
On 4/11/12 4:27 PM, Jacob Carlborg wrote:
> On 2012-04-11 04:50, Ary Manzana wrote:
>
>> Yes. In fact, JDT has a built-in Java compiler in their implementation.
>> Maybe it was easier to do it for them because the Java spec is easier
>> and doesn't fluctuate that much as the D spec. And JDT used that
>> compiler all over the place for getting all those IDE features.
>
> Exactly. Java hasn't changed much in the last 10 years (ok, just now it
> starts to changed again). JDT also contains a full compiler, not just
> the frontend, so it can compile all code. This would be nice to have for
> D as well but I think the frontend is the most important part.
>

Yes. I'm still thinking how could it be done but I have no idea at all how to do it. I can't figure out what that API would look like.

I like the idea of a new thread for this discussion. Eventually me or someone else should start it. :-P
April 12, 2012
On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu wrote:
> Would the JSON compiler output help?

I made a pull request a while ago that gives a lot more JSON output (https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to try to improve it to better meet the needs of an IDE, if anyone has any suggestions.
April 12, 2012
On 2012-04-12 03:31, Matt Peterson wrote:
> On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu wrote:
>> Would the JSON compiler output help?
>
> I made a pull request a while ago that gives a lot more JSON output
> (https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to
> try to improve it to better meet the needs of an IDE, if anyone has any
> suggestions.

I'm pretty sure that the JSON output can _never_ be enough for what we want to do.

-- 
/Jacob Carlborg
April 12, 2012
On 2012-04-12 03:12, Ary Manzana wrote:

> Yes. I'm still thinking how could it be done but I have no idea at all
> how to do it. I can't figure out what that API would look like.

Yeah, designing API's are hard. I'm starting to think that a completely new compiler (or frontend) built for this from the start might be the best idea anyway. Then we don't care too much about keeping up and just let it take the time it takes. There are still a big amount of that D is very stable and pretty straight forward.

We don't need to _start_ with a compile time debugger or mixin evaluations :)

> I like the idea of a new thread for this discussion. Eventually me or
> someone else should start it. :-P

I think so too. You know, no one is stopping you :)

-- 
/Jacob Carlborg