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

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Aug 2 01:09:43 AEST 2001


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:
> > On 01-Aug-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > A change to allow the IL backend represent the mercury type array(T) by
> > > System.Array.
> > 
> > (1) Why would we want to do that?
> 
> We have been discussing these points here.  Pete was in a hurry and
> didn't really write out the rationale for the change.

I noticed ;-)

> This is still a little sketchy, but I will try to answer these based on
> our current thinking.  (Your input will be useful).

Currently I still favour representing all Mercury arrays as `System.Object[]',
because that approach is simple and I know it works.  I'm willing to consider
other approaches, but we need to think them through carefully to ensure that
they will work.

> 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[]?

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

> > (5) Why not represent array types in the MLDS using the existing
> >     `mlds__array_type', rather than adding extra fields to `mlds__mercury_type'?
> 
> As far as I can see mlds__array_type is intended to be a system array
> type, and is not necessarily safe.
> 
> Whereas array__array(T) is a safe array type with bounds checking.

OK.

> If we had an unsafe array type it might be a good match for
> mlds__array_type.

I think you meant to say "safe" rather than "unsafe" there.

> I didn't think the way Pete implemented this was very elegant, so I
> volunteered to change it.
> 
> 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.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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