[clean-list] About abstract synonym types...

[Fergus Henderson]

On 05-Feb-2004, Arjen van Weelden <arjenw@cs.kun.nl> wrote:
> Fergus Henderson wrote:
> >I have my own questions about abstract synonym types in Clean 2.1:
> >
> >	- how do they interact with type classes?
> 
> They are abstract types, so another module can define instances on that 
> type, but it cannot make use of the type implementation.
> Knowing the concreet type does not allow you to use instances of the 
> concreet type on it.

What happens if an abstract type synonym is used to give two different
instance declarations for the same type?

For example, what happens if module A defines an abstract type T1 as a
synonym for type T2, and module B imports module A and declares both
T1 and T2 to be instances of a type class C, with different method
definitions?

> >	- how do they interact with separate compilation?
> >	  Does changing the definition of an abstact synonym type
> >	  require recompiling modules that import the module which
> >	  defines it?
> 
> They should not force compilation of other modules,

I agree.  But this is very difficult for an implementation to support
if the implementation compiles to a strongly-typed language that doesn't
support type synonyms, such as C++, Java, C#, JVM, or CLR.

Supporting separate compilation properly would require mapping the
abstract type to a different target language type than the one to which
its corresponding concrete type gets mapped to.  Then this raises
all sorts of complications when you have e.g. lists of functions
which return the abstract type, because those would no longer be
representation-compatible with lists of functions which return the
concrete type.  The compiler would need to insert implicit representation
conversion operations in some places, and those implicit conversions
would have cost O(N) where N is the length of the list.

Conversely, if you instead map the abstract type to the same target
language type as the concrete type is mapped to, this would break the
nice separate compilation properties that we want, namely that only
changes to a module's interface require recompilation of dependent modules.

> >	- has the Clean team considered how abstract synonym types
> >	  should be supported if compiling to a strongly-typed target
> >	  language that does not support abstract synonym types,
> >	  such as C++, Java, the JVM, or the .NET CLR?
> 
> I don't know, but the types are abstract and can therefore not be 
> transfered between languages without explicit user marshalling code.

The types are only abstract in other modules -- in the module that defines
the types, their concrete definition should be visible.  So it might make
sense to transfer the data from that module to code written in another
language.

-- 
Fergus Henderson <fjh@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.