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.
