> >>>>> On Thu, 03 Dec 92 08:13:17 +0000, Simon L Peyton Jones <[EMAIL PROTECTED]>
>said:
> Simon> Why do you need to drop the (..) when it turns into a "data" decl?
> Simon> You only need do so if you want it to be abstract!
> Simon> But "type" decls can't be abstract; the (..) reminds you of this.
>
> I don't want reminding. I know it isn't abstract, but for the sake of
> the importing module I like to pretend it is.
In that case, perhaps you should always use data declarations (with a
dummy constructor) rather than type synonyms. Some compilers will give
you better error messages this way, and a good compiler might eliminate
the extra constructor anyway (depending on how good a strictness
analyser it has!).
Abstract type synonyms would be an interesting addition to the language,
and I can't see any particular problem (we already have the mechanism
we'd need, in order to import abstract data types). Is the idea
worth resurrecting?
For example,
module F(S,T) where
type S a = (a,a)
data T a = C a a
could have the interface:
interface F where
type S a
data T a
Perhaps the fact that a type is a synonym/datatype should also be
hidden in the interface? Obviously a deriving clause would give the
game away, but otherwise it probably shouldn't be important whether an
abstract type is implemented by a synonym or a datatype. For example,
interface F where
type S a
type T a
Are there any problems with this?
Kevin
