To answer your questions ...
- Is the above view of type synonyms really equivalent to the
Haskell report's definition?
(Above view: consider the type and it's synonym to be distinct but
with implicit bidirectional coercion)
Almost. In some places, synonyms are not allowed. Your scheme
would seem to allow synonyms anywhere at all. (Instance declarations
cannot use synonyms).
- If so, wouldn't it be a better alternative which allows the
introduction of more general coercion functions later?
Type synonyms are a very simple, syntactic way of abbreviating types.
As presently used, coercions don't make sense. A synonym is simply an
abbreviation used in type signatures.
- Can it be used to replace or simplify the notion of `newtype'?
(Why were `newtype' declarations introduced in the first place?)
Newtype is an entirely different creature. With newtype, explicit
coercions guarantee that a value has a single, unique type (principal
type). Type synonyms don't get in the way or principal types because
they are just syntactic abbreviations and can be expanded away.
The place where this all becomes crucial is when looking up instances
associated with types. Type synonyms are always removed when looking
up instances. If you have
x :: String
then when an instance associated with x is needed, it will always expand
String to [Char] and fetch instances associated with lists. Now if
the types created by type synonyms were somehow distinct (capable of
carrying different instances), you would have to be able to know
exactly whether something is String or [Char] to understand the
semantics of the program. If the coercions are implicit, things get
very confusing. Newtype carries separate instances (unlike synonyms)
but requires explicit coercion so there is no possibility of confusion.
The only special thing about newtype is that it implies no additional
representational overhead, unlike using an ordinary wrapper type (I'm
convinced there's never any overhead for newtype but Mark Jones isn't;
but we both agree that the overhead is minimal). Representational
efficiency and program clarity are the reasons to have newtype instead
of using wrapper types. In the bigger picture, though, the concept of
`make a type T whose internal structure is identical to another type U
but which is distinct' is a common idiom in other programming
languages that we felt should be in Haskell directly and efficiently.
John Peterson
[EMAIL PROTECTED]
