There is a couple of questions.

1. What about interoperability of D and .NET platform?
2. What is the difference between pure D and D for .NET?
3. Can I write code on pure D and then compile it to MSIL and use it further in .NET environment?
4. Are there many libraries for D? Can D just use C\C++ dll's without pain for programmer?

Thank you in advance)))

On 29-07-2012 17:30, EngineerSpock wrote:
> There is a couple of questions.
>
> 1. What about interoperability of D and .NET platform?

You should be able to write C routines in D that .NET's P/Invoke can call.

> 2. What is the difference between pure D and D for .NET?

D for .NET is dead because .NET is too limited to represent the language, so describing this isn't really worthwhile. :)

> 3. Can I write code on pure D and then compile it to MSIL and use it
> further in .NET environment?

No. Sorry to ruin your hope, but D on .NET is a dead end.

> 4. Are there many libraries for D? Can D just use C\C++ dll's without
> pain for programmer?
>
> Thank you in advance)))

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

Alex Rønne Petersen:

> .NET is too limited to represent the language,

Can you tell us why?

Bye,
bearophile

On 29-07-2012 17:36, bearophile wrote:
> Alex Rønne Petersen:
>
>> .NET is too limited to represent the language,
>
> Can you tell us why?
>
> Bye,
> bearophile

Array slices. The .NET type system has no way to represent them because it's designed for precise GC, and array slices allow interior pointers in the heap (as opposed to the stack when passing a field of an object by reference to a function, or whatever).

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 7/30/2012 12:30 AM, EngineerSpock wrote:
> There is a couple of questions.

> 4. Are there many libraries for D? Can D just use C\C++ dll's without
> pain for programmer?
>

There are a number of libraries covering different domains, some active some not. Also, D is binary compatible with C, so you can use existing C libraries with D (see Derelict[1] and Deimos[2] for examples).

There's also some support for binding with C++, but AFAIK it's not as reliable as the C interface due to incompatibilities between C++ compilers. There are also going to be limitations regarding certain C++ features. I /assume/ it will mostly work with DMC and GCC. But someone else will have to tell you how usable it is.

[1] https://github.com/aldacron/Derelict3
[2] https://github.com/D-Programming-Deimos

On Sun, 29 Jul 2012 18:32:08 +0200, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 29-07-2012 17:36, bearophile wrote:
>> Alex Rønne Petersen:
>>
>>> .NET is too limited to represent the language,
>>
>> Can you tell us why?
>>
>> Bye,
>> bearophile
>
> Array slices. The .NET type system has no way to represent them because it's designed for precise GC, and array slices allow interior pointers in the heap (as opposed to the stack when passing a field of an object by reference to a function, or whatever).

So one couldn't simply use a two-level system, with a slice referencing an
array, and holding an offset and a length?

-- 
Simen

On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
> On 29-07-2012 17:36, bearophile wrote:
>> Alex Rønne Petersen:
>>
>>> .NET is too limited to represent the language,
>>
>> Can you tell us why?
>>
>> Bye,
>> bearophile
>
> Array slices. The .NET type system has no way to represent them because
> it's designed for precise GC, and array slices allow interior pointers
> in the heap (as opposed to the stack when passing a field of an object
> by reference to a function, or whatever).
>

I think all of CTFE-D should map to .NET without much hassle.

struct ArraySlice<T>{
    private T[] storage;
    private ulong start;
    private ulong len;

    public ArraySlice<T> slice(ulong a, ulong b){
        if(a>b||b>len) throw new BoundsError("...");
        return new ArraySlice<T>(storage, start+a, b-a);
    }

    public ulong length(){ return len; }
    public Pointer<T> ptr(){ return new Pointer<T>(storage, start); }
    // ...
}

Performance will suffer of course.

On 07/29/2012 07:00 PM, Timon Gehr wrote:
> On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
>>>> .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them because
>> it's designed for precise GC, and array slices allow interior pointers
>> in the heap (as opposed to the stack when passing a field of an object
>> by reference to a function, or whatever).
>>
>
> I think all of CTFE-D should map to .NET without much hassle.
>

This could get a little hairy:

struct S{
    int x,y;
}

void main(){
    S s;
    auto p = &s.y;
    // ...
}

It would have to be translated to something like (pseudo-code)

class S{
    int x;
    int y;

    S copy(){...}
}

class SyPointer : Pointer<int> {
    private S instance;
    override int deref(){ return instance.y; }
    override void derefAssign(int y){ instance.y = y; }
}

Out of the window goes native value type support.

On 07/29/2012 01:11 PM, Timon Gehr wrote:
> On 07/29/2012 07:00 PM, Timon Gehr wrote:
>> On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
>>> On 29-07-2012 17:36, bearophile wrote:
>>>> Alex Rønne Petersen:
>>>>
>>>>> .NET is too limited to represent the language,
>>>>
>>>> Can you tell us why?
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> Array slices. The .NET type system has no way to represent them because
>>> it's designed for precise GC, and array slices allow interior pointers
>>> in the heap (as opposed to the stack when passing a field of an object
>>> by reference to a function, or whatever).
>>>
>>
>> I think all of CTFE-D should map to .NET without much hassle.
>>
>
> This could get a little hairy:
>
> struct S{
> int x,y;
> }
>
> void main(){
> S s;
> auto p = &s.y;
> // ...
> }
>
> It would have to be translated to something like (pseudo-code)
>
> class S{
> int x;
> int y;
>
> S copy(){...}
> }
>
> class SyPointer : Pointer<int> {
> private S instance;
> override int deref(){ return instance.y; }
> override void derefAssign(int y){ instance.y = y; }
> }
>
> Out of the window goes native value type support.

I still always thought it funny that we didn't reach for it anyways.  It seems like the VMs can weaken performance significantly, but they should always be able to implement D's semantics.  It's a matter of finding effective hacks.

On 29-07-2012 18:51, Simen Kjaeraas wrote:
> On Sun, 29 Jul 2012 18:32:08 +0200, Alex Rønne Petersen
> <alex@lycus..org> wrote:
>
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
>>>> .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them
>> because it's designed for precise GC, and array slices allow interior
>> pointers in the heap (as opposed to the stack when passing a field of
>> an object by reference to a function, or whatever).
>
> So one couldn't simply use a two-level system, with a slice referencing an
> array, and holding an offset and a length?
>

That could work, but it wouldn't be compatible with D as it is now.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org