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

[Tyson Dowd]

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.
This is still a little sketchy, but I will try to answer these based on
our current thinking.  (Your input will be useful).


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

They should all be compatible with System.Array.

> (3) Why would we want to do what your change actually does
>     (as opposed to what the log message says it does)?
> 
>     Note that I previously wrote on mercury-reviews that
>     "If you're talking about implementing the Mercury type `array(int)' 
>     as the IL type `int []', then I don't think it is a good idea"
>     <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-reviews/mercury-reviews.0107/0338.html>.
> 
>     So if you think it is a good idea, I would like you to please explain why.

At the moment we are going with the plan to represent array(T) as
System.Array and implement array.m in terms of the methods on
System.Array.

We will use some RTTI in array__init to create instances (using the
CreateInstance method) of System.Array that are really int[] or
'Byte'[].  (this is a bit hairy right now but I think it can be done in
time).

> (4) Is there any point in changing the compiler in this way without
>     fixing library/array.m?

Yes, interop.

We can generate an interface to System.Array and get all the array
manipulation we want.

Of course it would be nice to fix library/array.m too.  We can put it on
the wish list. 

But for the moment all we really want to be able to do is consume arrays
without demanding they change type.

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

The two are not supposed to be compatible, although on some backends
they might be. 

They are certainly not on the C backend.

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


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.  It can be mapped to MR_Word if you wish, or T[],
or System.Array, or whatever else is suitable for your backend.

For the IL backend it will be T[] unless T is actually a type variable,
in which case it will be System.Array.

But I'm just trying this out now, there might be difficulties.

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