> kh> In that case, perhaps you should always use data declarations (with a
> kh> dummy constructor) rather than type synonyms. Some compilers will give
> kh> you better error messages this way, and a good compiler might eliminate
> kh> the extra constructor anyway (depending on how good a strict
> On Fri, 18 Dec 92 15:42:42 GMT, kh <[EMAIL PROTECTED]> said:
> > On Thu, 03 Dec 92 08:13:17 +, 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!
> S
| 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
|
| Are there any problems with this?
The main difficulty is deciding whether the signatures in the
int
> > On Thu, 03 Dec 92 08:13:17 +, 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 th
> On Thu, 03 Dec 92 08:13:17 +, 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 d
Why do you need to drop the (..) when it turns into a "data" decl?
You only need do so if you want it to be abstract!
But "type" decls can't be abstract; the (..) reminds you of this.
Some of us have been musing on how to provide an abstract version of
"type" too, but that didn't get into the la
Consider the following :-
>module Oberon_Integer
>type Oberon_Integer = Integer
>module Parser
>import Oberon_Integer(Oberon_Integer(..))
If I drop the "(..)" HBC complains (and correctly so as far as I'm
aware). However, having to tag types with "(..)" make it tedious to
change implem
