[m-rev.] [dotnet-foreign] diff: use System.Array for mercury arrays
Tyson Dowd
trd at cs.mu.OZ.AU
Thu Aug 2 19:16:42 AEST 2001
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
--------------------------------------------------------------------------
More information about the reviews
mailing list