"EngineerSpock" <fofanov1988 bk.ru> writes:

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

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

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

"bearophile" <bearophileHUGS lycos.com> writes:

Alex Rønne Petersen:

 .NET is too limited to represent the language,

Can you tell us why?

Bye,
bearophile

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

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

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Sun, 29 Jul 2012 18:32:08 +0200, Alex R=C3=B8nne Petersen <alex lycus=
.org>  =

wrote:

 On 29-07-2012 17:36, bearophile wrote:
 Alex R=C3=B8nne 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 becaus=

e  =

 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

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

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

"EngineerSpock" <fofanov1988 bk.ru> writes:

And what can you say about this:
http://dnet.codeplex.com/

"Peter Alexander" <peter.alexander.au gmail.com> writes:

On Sunday, 29 July 2012 at 17:36:51 UTC, EngineerSpock wrote:
 And what can you say about this:
 http://dnet.codeplex.com/

I can say the last commit was 3 years ago. Make your own 
conclusions.

"ProHeckler" <ph2030 yourfuture.com> writes:

EngineerSpock wrote:
 And what can you say about this:
 http://dnet.codeplex.com/

You came to the right group: buy your dildo here. 

"ProHeckler" <ph2030 yourfuture.com> writes:

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?

D is a programming language. Why don't you go to your metrosexual sushi bar 
and "talk programming", bitch? 

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

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.

"ProHeckler" <ph2030 yourfuture.com> writes:

Chad J wrote:

 I still always thought it funny that we didn't reach for it anyways.

"we"? Surely you meant you ("I"). Hmm? You saw the movie (?). "The Quick, 
and the Dead". You cannot be quick, for you are not "quick". Thank you, you 
are not a gunslinger. (Romance, timeout please). "They" "love" the quick 
shooter, huh. Analogyy to "those who gab, have nothing to say"? (I don't 
know 'analogy' from 'metaphor'). What does "reach for it" mean? Something 
about 1984 chimes true.

Oh, but "they" "didn't know". Isn't *that* convenient. Because if you as an 
individual don't know, it is a crime. But if those in on the take do wrong, 
it's a free ride to being the next horror, and it becomes "law".

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Sunday, 29 July 2012 at 17:11:55 UTC, Timon Gehr wrote:
 This could get a little hairy:

 struct S{
     int x,y;
 }

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

How does C++ for .NET handle this?

"ProHeckler" <ph2030 yourfuture.com> writes:

Vladimir Panteleev wrote:
 On Sunday, 29 July 2012 at 17:11:55 UTC, Timon Gehr wrote:
 This could get a little hairy:

 struct S{
     int x,y;
 }

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

 How does C++ for .NET handle this?

It didn't. Microsoft is about to do that. I'm thinking I should be a little 
asheamed. What do you think? 

"ProHeckler" <ph2030 yourfuture.com> writes:

Timon Gehr wrote:

 This could get a little hairy:

A boy's dream? 

"ProHeckler" <ph2030 yourfuture.com> writes:

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.

No, you cannot wank as an adolescent forever. There are too many males and 
you know it so you are afraid of "growing up", but it really is not up to 
you. 

"David Piepgrass" <qwertie256 gmail.com> writes:

On Sunday, 29 July 2012 at 16:32:10 UTC, Alex Rønne Petersen 
wrote:
 On 29-07-2012 17:36, bearophile wrote:
 .NET is too limited to represent the language,

 Can you tell us why?

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

D is theoretically designed for precise GC, too. But in .NET you 
can only have a reference to an array as a whole, so a slice must 
be represented as an array, offset and length. The real problem I 
see is that in D you can have a slice that does *not* refer to an 
array on the GC heap, such as a slice on a non-GC heap, or on the 
stack (currently, in fact, in D you can easily make pointers and 
slices that point to stack data to outlive the stack frame, which 
the 'safe' .NET type system inherently prevents).

.NET allows one to break the type system using pointers (in 
functions marked 'unsafe'), so as far as I can tell D for .NET 
could theoretically do everything that native D does, but with 
some annoying caveats mainly related to garbage collection. For 
instance, in a slice, I believe you can't use the same memory 
word to refer to an array on the GC heap OR an array that is not 
on the GC heap (unless you want to pin all your arrays, and you 
really don't). IIUC, doing so can crash the garbage collector.

I'm thinking that a .NET D slice would be implemented as a 
reference to a GC array and two integers (start and length). If 
the slice refers to a non-GC array, it would be stored in the 
same space, as a null reference, a pointer cast to IntPtr, and a 
length. However, this would make the code for accessing a slice 
rather clumsy and/or inefficient.

.NET has other limitations too, but again I expect there would be 
workarounds.

"ProHeckler" <ph2030 yourfuture.com> writes:

David Piepgrass wrote:
 On Sunday, 29 July 2012 at 16:32:10 UTC, Alex Rønne Petersen
 wrote:
 On 29-07-2012 17:36, bearophile wrote:
 .NET is too limited to represent the language,

 Can you tell us why?

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

 D is theoretically designed

That is to say it is non-designed.

"ProHeckler" <ph2030 yourfuture.com> writes:

bearophile wrote:
 Alex Rønne Petersen:

 .NET is too limited to represent the language,

 Can you tell us why?

He's playing you, sucker. 

"ProHeckler" <ph2030 yourfuture.com> writes:

Alex Rønne Petersen wrote:
 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. :)

That is "a lie" (save for you may not know). .net is a Microsoft product at 
the API-ish level. It "strikes a cord" with "real" programmers, surely. Alex 
needs to be more careful when he posts.  .net is not dead. Not even NOT 
relevant for D. D is at the language level. (AKA, "the language level"). 
"It", cannot address higher level concerns, for it is not even evolved or 
relevant as a child. "Lord of the Flies" and D, have something in common? 
Learning perhaps? Is D an island of childish thought "promogulated" with the 
zeal of an adolescent "guitar hero", "re"inventing "rock-n-roll" and wanking 
his pecker? The island is overloaded with comers. "freedom reigns", and then 
you grow up. Then what? The drug stops. You realize your enemy is 
formidable. Your scope has been small. But your enemy knew that all along. 
And you might even realize that pissing in the wind and beating it, was your 
same old spiel. The wind is not your enemy. And neither is time. You battle, 
and are too quick to battle, that which you do not know. I assure you that 
all you battle is time. And time is not interested in your childish games. 
You are going to lose. A war that does not exist, save for only your 
"lordness", which begs the question is D a lemon tree worthy of pissing on? 
I think it is dismissabke without conjecture. Exclude the masturbatory 
adolescnet males and you have... tada! What? Nothing? Guitar hero. Lord of 
the flies?

Close this wank room.

Mike Parker <aldacron gmail.com> writes:

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

"ProHeckler" <ph2030 yourfuture.com> writes:

Mike Parker wrote:
 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,

More ammo for a war that does not exist?

"ProHeckler" <ph2030 yourfuture.com> writes:

EngineerSpock wrote:
 There is a couple of questions.

 1. What about interoperability of D and .NET platform?

What about "it"? Are you a software developer or a Microsoft bitch?

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

There is no "D for .net". If you want that, pick your crime, do it, go to 
prison and ... nevermind.

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

Lame try troll. Your point was: "Is .net formidable?". If you work for 
Microsoft you hope so.

 4. Are there many libraries for D?

I can't answer that: I don't know.

  Can D just use C\C++ dll's
 without pain for programmer?

Hopefully not. (I'll expect my check in the mail for such promotion Ders). 
:P

 Thank you in advance)))

That was trite.