> >>>>> 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


Reply via email to