synonym type not allowed

[Alan Grover]

>Erik Zuurbier wrote:
>I have always assumed that the principle of type checking via type name
>equality rather than by equality following reduction to a canonical 'base
>representation' is desirable because it allows a programmer (software
>engineer) to distinguish types that are non-equivalent in the problem
>semantic domain (eg number of oranges and size of a file in bytes) but have
>identical representations in the implementation (eg int). The compiler can
>then help to ensure that one kind of data is not mistakenly used in place
>of the other.

This is the conclusion I came to, also. We should be aware of the
difference between the implementation and the semantics. Semantics is about
meaning and how something is used. So, in the current Clean implementation,
a type synonym expresses "same implementation" and "same semantics".
Algebraic types express the "different semantics". Here is an example that
demonstrates the problem if implementation and semantics aren't seperated:

On the Macintosh there is a very common type, OSType, which has the
semantics of "exactly 4 bytes, treated as an ID, and presented to humans as
4 characters". In all of the C/C++ environments, it is implemented as a
synonym of a 32 bit integer. In the printable domain this makes it
impossible to overload the equivalent of "toString" or operator "<<<".

As people have mentioned, using algebraic types can sometimes result in
having to reimplement many operations just to gain the benefits of
distinguishable types. That seems like unnecessary work. We'd like to be
able to say "type x is an Int, but I want to make distinct operations
especially for type x." Erik's example above starts with "int" (a
dimensionless number) and subclasses it to number of oranges (a dimensioned
number). If the same program were dealing with melons, there might be some
operations like:

class fruitOperations theFruit
	where
		numberOfCases :: theFruit -> Int
 		rateOfSpoilage :: theFruit -> Int

and one would expect the calculation for Oranges to cases to be different
from Melons to cases, and that spoilage rate depends on the type of fruit
(as well as how many are in close association). But, one would expect that
the "+" operator (and all other  Int operators) works exactly the same for
both.

What do you think about recognizing subclassing as a way of generating
types? (And I don't mean to replace Algebraic types).

---
"Alan Grover, Technical Pb" awgrover@umich.edu
Project Leader
Health Media Research Lab
Cancer Center