On 17-Feb-2000, Brian Boutel <[EMAIL PROTECTED]> wrote:
> On Thursday, February 17, 2000 7:02 PM, Fergus Henderson
> > Well, I remain unconvinced. In Mercury, we give the user control
> > over whether instance declarations are exported or not, and it
> > works quite nicely, IMHO. I think the problems that you are referring
> > to below are only problems if in addition to allowing private instance
> > declarations you also allow multiple or overlapping instance declarations.
> > But I would assign the blame for these problems to multiple/overlapping
> > instance declarations, not to having control of when instance
> > declarations are exported.
>
> I don't think this is the case. Suppose there is the present Haskell rule -
> only one C-T instance per program - with the addition that local "private"
> instances may be declared, which shadow the global instance in that module.
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.
> Are you saying that it is
> illegal in Mercury to import into a module using one C-T instance, a
> function which was declared in a module using a different C-T instance,
> even if you don't import the instance, and the only place where it is used
> is in the imported function?
Yes. Not because of the details of how things are imported or used,
but simply because the program contains two different definitions
of the same C-T instance.
> > In Mercury there can't be another matching instance declaration
> > in scope, since Mercury does not allow multiple or overlapping
> > instance declarations. Thus we preserve referential transparency.
>
> In my example there is no place with multiple instances in scope. It's
> quite clear everywhere which instance is to be used, the problem is that
> normal semantics-preserving transformations break.
Those problems would indeed be serious ones; the way we implement
inter-module optimization in the Mercury compiler relies on
referential transparency being maintained in that sense, and it
would break if we allowed multiple instance declarations for the
same class and type. That's one of the reasons why we don't support
overlapping instance declarations.
But those problems do not arise for Mercury as it is currently defined.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
