[m-dev.] abstract equivalence types & .NET / JVM

[Tyson Dowd]

On 18-Apr-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Mercury allows modules to define abstract types which are implemented
> as type synonyms.
> 
> Unfortunately there is no directly support for this in .NET or JVM.
> So we need some way of handling abstract equivalence types
> for the .NET and JVM back-ends.
> 
> Tyson and I have discussed several possible approaches.
> All of the different approaches suck in one way or another,
> so it's just a question of finding the one that sucks the least.
> 
> 1.  Our current approach for the high-level C and .NET back-ends is to use
>     `--no-high-level-data';
>     i.e. map everything except the basic types to `Object'.
> 
>     This is very bad for interoperability (which is the whole point of
>     these back-ends), and probably very bad for performance too).
>     It also has problems with abstract equivalence types that
>     are defined as equivalent to basic types (such as `int' or `float').

Actually, for .NET we currently map everything to MR_Word, which is
defined as Object[].  This is more by accident than by design.  A few
minor flaws would be fixed by mapping to Object instead, but the main
problem will remain.

The dotnet-foreign branch also supports 
	:- pragma foreign_type(....).
that allows you to define a mercury type that maps down to a .NET type.
But this also has the same problems with abstract equivalence types.

> 2.  Rather than mapping *everything* to `Object', we could be a bit more
>     selective.  We could have the Mercury compiler generate code which uses
>     `Object' for all parameters whose type is an abstract data type,
>     with the called procedure internally casting to and from the type
>     that the ADT is implemented as. 
>     
>     But this is still bad for both efficiency and interoperability.
>     Also it is not easy to implement.  It requires the Mercury compiler not
>     expand abstract equivalence types until after code generation, which is
>     hard.  And it requires modifications to code generation.

We also discussed a variant of this scheme where you would use a
specific type name other than Object which you define locally, but this
doesn't help either.

The main problem with this proposal is that internally casting to and
from the "abstract" type and its equivalence can be arbitrarily
expensive.  For example,  if foo == int, then you can't convert
list(foo) to list(int) without traversing the entire list, but
internally code may expect list(int) and not list(foo).

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------