[m-rev.] [dotnet-foreign] diff: use System.Array for mercury arrays

[Tyson Dowd]

On 02-Aug-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 01-Aug-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > On 01-Aug-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > You want array(T) to be System.Array so that it is compatible with 
> > int[] and object[] (and all other sorts of array).
> > 
> > We want it to be compatible with those types because we need to
> > inteoperate with those types.
> 
> OK.  For the .NET back-end, it makes sense to favour interoperability
> over performance, so let's choose whatever representation is best
> for interoperability.
> 
> > > (2) I don't think your change does that.
> > >     Your change seems to represent array(T) by the type "T[]",
> > >     which is not the same as System.Array.
> > 
> > Yes.  This is correct.  It is a little bit of a bug.  
> > 
> > array(T) should be System.Array
> > array(int) should be int[] 
> > array(list(int)) should be Object[][] or list_1[] with high level data.
> 
> Hmm, so array(T), where T is a type variable, gets treated as a special case?
> That's a bit non-orthogonal.  I'm not yet sure if it will work.
> What happens with array(array(T))?  Does that become System.Array[]?

Yes.

All the array(T) ====> System.Array mapping is intended to do is allow
e.g. array(int) *or* e.g. array(object) to be passed where array(T) is
written, without requiring an O(N) conversion.

If it does that, we shouldn't have any problems.  So array(array(T)) can
be System.Array[], and it would be compatible with the type
array(array(int)) (which is int[][]).

It would also be compatible with System.Array, so we can use all the
methods in array.m that operate on System.Array.

> This approach will require upcasts to convert from System.Array
> to e.g. int32[] when calling routines such as e.g. array__init or
> array__make_empty_array, which return values of type array(T),
> from a context that is expecting a specific array type, e.g. array(int).

Upcasts?  Isn't this a downcast?  System.Array is the superclass of all
arrays.

But yes, when you get an array(T) but you expect an e.g. array(int) you need
to insert a castclass to be verifiable.

> These upcasts will be similar to the unboxing that we currently do
> to convert from System.Array to e.g. int when calling routines
> that return values whose type is a type variable,
> from a context that is expecting a specific type.

I think you meant System.Object to e.g. int

But otherwise it is very similar.

> I was a bit worried about difficulties with arrays of arrays, and
> such like, because although `array(array(int))' is an instance
> of `array(array(T))', `int[][]' isn't logically an instance of
> `System.Array[]'.  (The difference is that Mercury arrays are immutable,
> whereas .NET arrays are mutable.  `int[][]' isn't an instance of
> `System.Array[]' because you can't insert arbitrary `System.Array'
> values into it.)  However, I think .NET uses covariant arrays,
> which I think will mean that it will actually work.

Yes, arrays are covariant.  It is a bit disturbing, but it does work.

> > I'm working on a change that adds mlds__mercury_array_type, which will
> > be a safe array type.
> 
> OK, good, that does sound like a better way to do it.

Note that I'm not adding any special support for safe arrays in C, the
C backend will just map mlds__mercury_array_type to MR_Word and use the
handwritten implementation.  But the Java and .NET backend should be
able to map it to the system array type.

Tyson.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------