Type synonyms revisited

[Erik Zuurbier]

A while back I started a discussion about type synonyms. One of my
questions was not answered though. I repeat the line of discussion for that
question. At the end I repeat the question.

*****************

:: MyType :== (Int,Real)

instance == MyType
where   (==) (i1,r1) (i2,r2)    = i1==i2 && r1==r2
        (==) _ _                = False

This gives:
Error [Tryit.icl,17,==]: MyType type synonym used as instance

Will type synonyms be allowed here in a future version of the Clean
compiler, or is there some fundamental reason to disallow them?

***************

Type synonyms can not be allowed as instances of type classes. At least,
not as they are now. The problem is that the compiler can not determine
whether the expression (3, 4.0) is of type (Int, Real) or of your MyType.

For example,

Start = (3,4.0) == (3,5.0)

What should the answer be? Maybe there is yet another type synonym for
(Int, Real) that does not support equality.

:: AnotherType :== (Int, Real) // equality is not defined for this type

For these reasons, type synonyms are not allowed as instances.

*************

You may regard instances of type synonyms as an instance of the basic type,
then you don't have the problem that the compiler cannot determine whether
the expression (3, 4.0) is of type (Int, Real) or of your MyType. You
always use the instances of type (Int, Real).

**************

That is simple. That brings down the word synonym to what the word actually
means: a different word for exactly the same thing. I cannot immagine that
language developers have never thought of this. A synonym type would be
reduced to a syntactic issue. What do we lose that way?

**************

You're right. Language developers did think of this. However, the problems
remain. Let me clarify my statement with an example: 

:: Complex :== (Int, Int)
:: Ratio   :== (Int, Int)

instance == Complex where
  (==) (a, b) (c, d) = a == c && b == d

instance == Ratio where
  (==) (a, b) (c, d) = a * d == b * c

Start = (3, 4) == (6, 8)

*************

Now you have two instances for the type (Int, Int)! Of course this should
be illegal. But IMHO type synonyms are not the language construct to
introduce new abstract datatype. It is mainly for humans to write and read
the source code.

*************

There is yet another problem. Overlapping instances are not allowed in
Clean. If you import StdTuple (included in StdEnv), an instance for tuple
equality is already defined.
You can not overrule this general equality for a two-tuple of Ints.

************

OK, this reason disables the example above, but regarding type synonyms
really as synonyms should be possible anyway.

************

So far the summary. So say we just do not import StdTuple, and we would
regard type synonyms as just a syntactical construct, a shorthand for a
type signature, not a type definition by itself that can differ from the
type it is a synonym for in the set of functions that are defined for
it,... the question remains: what do we lose if we do that?

I have the impression that Haskell has both kinds of synonyms.

Regards Erik Zuurbier