On Friday, February 18, 2000 1:46 AM, Fergus Henderson
[SMTP:[EMAIL PROTECTED]] wrote:
>
> Mercury allows private instances, but it does not allow shadowing.
> For any given class and type, there can only be one instance;
> that instance can be public, or private, but not both.
>
> If you allow shadowing, then you have multiple instance declarations
> for the same class and type, and in that case you do have problems.
> But again, I blame those on allowing shadowing, not on having
> control over when instance declarations are exported.
>
> > Suppose the normal Prelude instance decl for type Integer as an
instance
> > of Num is shadowed in Module A by a private Num-Integer instance decl.
>
> That kind of thing is not allowed in Mercury; if there is an instance
> for `Num Integer' (in Mercury syntax it would be `num(integer)')
> in one module, then you're not allowed to have an instance for that
> same combination in any other module in the same program.
>
OK, I understand now. But what advantage does explicit control of instance
import/export give you over the current Haskell rule?
In Haskell, you can have at most 1 C-T instance, and that is visible in
every module in the program which can be reached by a chain of
import/export declarations from the declaring module.
In Mercury you can have at most 1 C-T instance, but there may be more
places where it is not visible. There does not seem to be anything you can
do in those places that you could not do if the C-T instance were visible
there.
But this is not quite the problem I was addressing, which was having
multiple C-T instances in the program, but using explicit import/export
control to ensure that only one was in scope at any place. My point was
that exported function definitions which depended on a C-T instance could
not be imported into a module in which a different C-T instance was in
scope without causing serious problems.
--brian
