On 1/23/2015 2:42 AM, Abdulhaq wrote:
> Calypso sounds fantastic but seems very tied to one compiler - we all need to
> know if yourself and Walter are content with that, for instance.

Yes, it's tied to clang++. It may not even work on all the platforms we support. But that's no matter for now.

On Friday, 23 January 2015 at 10:52:26 UTC, Walter Bright wrote:
> On 1/23/2015 12:34 AM, Max Klyga wrote:
>> I remember Walter arguing against this type of solutions because it requires a
>> C++ compiler to be bundled with D.
>
> Yes.
>
>> Does that mean that now we are adopting this path instead of 'extern(C++)' ?
>
> No. I presume it will work much like htod.exe, and extern(C++) will be what Calypso generates.

AFAICS it is not the way Calypso works right now, it does direct imports of C++ headers from D modules via `modmap (C++) "headerofyourdll.h"` without generating intermediate D binding module:
http://forum.dlang.org/post/nuiihxfcgjnaougivker@forum.dlang.org

On Friday, 23 January 2015 at 10:53:47 UTC, Walter Bright wrote:
> On 1/23/2015 2:42 AM, Abdulhaq wrote:
>> Calypso sounds fantastic but seems very tied to one compiler - we all need to
>> know if yourself and Walter are content with that, for instance.
>
> Yes, it's tied to clang++. It may not even work on all the platforms we support. But that's no matter for now.

When you say "for now", does that imply that at some time in the future it may matter, in which case isn't it better to get these issues thrashed out now? Is this a potential dead end?

On 1/23/2015 3:22 AM, Abdulhaq wrote:
> On Friday, 23 January 2015 at 10:53:47 UTC, Walter Bright wrote:
>> Yes, it's tied to clang++. It may not even work on all the platforms we
>> support. But that's no matter for now.
>
> When you say "for now", does that imply that at some time in the future it may
> matter, in which case isn't it better to get these issues thrashed out now? Is
> this a potential dead end?
>

We don't need a perfect solution immediately. We do need a solution that's better than nothing, we can build on that as required.

On Friday, 23 January 2015 at 11:26:07 UTC, Walter Bright wrote:
> On 1/23/2015 3:22 AM, Abdulhaq wrote:
>> On Friday, 23 January 2015 at 10:53:47 UTC, Walter Bright wrote:
>>> Yes, it's tied to clang++. It may not even work on all the platforms we
>>> support. But that's no matter for now.
>>
>> When you say "for now", does that imply that at some time in the future it may
>> matter, in which case isn't it better to get these issues thrashed out now? Is
>> this a potential dead end?
>>
>
> We don't need a perfect solution immediately. We do need a solution that's better than nothing, we can build on that as required.

I actually agree (though I am nowhere near as well informed as most others on this forum) that Calypso is the way to go, however ISTM there are large implications that go with that decision. The infrastructure that Calyspo depends on is not something, IMO, that you "can build on as required" to address missing platforms, for instance. Gazing into my crystal ball I'd say that 5 years down the road there will be many D libraries with significant dependencies on C++ (Calypso bound) to the extent that the great unwashed will view D as a language that is only practicable on platforms supported by clang++. For me that is fine, but I suspect not fine for others. For instance, I would view Qt and VTK as key bindings. Others will want numeric libraries etc. etc..

I should also point out that D doesn't have 'nothing' in terms of alternatives, there exist other more traditional binding-based technologies that could flourish with 'official' support. Since I have a hand in one of those I should point out that I think Calypso, if it does what I think it does, will work better in terms of integration, speed etc. and from my personal perspective is therefore better. My goal is to have Qt, VTK, linear algebra, matrices etc., available for D (linux and Windows) and I'm not fussed exactly how it is done.

On 2015-01-23 11:52, Walter Bright wrote:

> Yes, it's tied to clang++. It may not even work on all the platforms we
> support. But that's no matter for now.

At least Clang supports all platforms we support.

-- 
/Jacob Carlborg

On 1/23/15 12:34 AM, Max Klyga wrote:
> I remember Walter arguing against this type of solutions because it
> requires a C++ compiler to be bundled with D.

It doesn't require as much as makes it usable if you have it. Calypso requires dmd + clang++ is the natural dependency direction.

> Does that mean that now we are adopting this path instead of
> 'extern(C++)' ?

I see it more like "with the help of" rather than "instead of". The extern(C++) feature is porcelain over a bunch of compiler internals that make it possible to use C++ in conjunction with D.

We should foster and support "plugin" tools like Calypso that add value to the D environment.


Andrei

On 1/23/15 2:42 AM, Abdulhaq wrote:
> Calypso sounds fantastic but seems very tied to one compiler - we all
> need to know if yourself and Walter are content with that, for instance.

We should make the life of plugin writers easy. They do get to decide what other prerequisites their tools have.

Andrei

On 2015-01-23 17:02, Andrei Alexandrescu wrote:

> We should make the life of plugin writers easy. They do get to decide
> what other prerequisites their tools have.

Are you suggesting to have a general plugin architecture in DMD? That would be very cool, especially if they can be installed as Dub packages. Although I'm guessing there will be complains that it might create different flavors of D. And how will multiple plugins interact with each other?

-- 
/Jacob Carlborg

On 1/23/15 8:57 AM, Jacob Carlborg wrote:
> On 2015-01-23 17:02, Andrei Alexandrescu wrote:
>
>> We should make the life of plugin writers easy. They do get to decide
>> what other prerequisites their tools have.
>
> Are you suggesting to have a general plugin architecture in DMD?

It's something worth thinking about.

> That
> would be very cool, especially if they can be installed as Dub packages.
> Although I'm guessing there will be complains that it might create
> different flavors of D. And how will multiple plugins interact with each
> other?

As of now I'm unclear on the details. Supporting plugins seems to be an interesting recent trend in compilers.


Andrei