[m-dev.] Foreign type compare and unification

[Mark Brown]

On 24-May-2002, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Fri, May 24, 2002 at 04:12:58PM +1000, Mark Brown wrote:
> > > I don't think so.  As I understand it, you still want some random
> > > distant piece of code to be able to declare that string is an instance
> > > of comparable, and my code should benefit from it.
> > 
> > Urk, no.  I was making the unstated assumption that the instance
> > declaration in question is visible in the given scope.
> 
> Ok, now just to be clear, are you suggesting that instance
> declarations should have effect only where they're visible, or were
> you just not considering the case I'm interested in where an unseen
> instance declaration mysteriously affects my code?

I was not saying anything at all about that case.  Declarations that
are not visible should by definition have no effect.

> > I would argue that
> > > unless string is made an instance of comparable in the interface of
> > > the module that defines string, or my code has such a declaration,
> > > then my code should not consider string to be an instance of
> > > comparable.  I'd rather get a compile-time error (not a link-time
> > > error) if my code tries to compare two strings, or passes strings to a
> > > predicate that does so.
> > 
> > Compile-time error is fine.  Link-time error is not as good, but still
> > acceptable to me.  With default instance methods, though, you would get
> > no error at all, but the behaviour of your program could change.  It is
> > this that I am opposed to.
> 
> Again, to be sure we're talking about the same thing:  right now
> someone can add an instance declaration to one module in the program
> that would make another module fail to link properly.  Call that
> problem 1.  I'm still not sure whether you propose to tolerate that
> problem.

I have proposed nothing of the sort.

> You are saying, though, that with default instance
> declarations, someone could add a default instance declaration which
> would make another module behave incorrectly.  Call that problem 2.
> This is clearly worse, and you can't accept that.  I'd argue that both
> are unacceptable.
> 
> But if the "defaultness" were attached to the *class* declaration
> instead of the *instance* declaration, the second problem can't
> happen, because a module can only be affected by visible classes,
> though it can be affected by invisible instance declarations for
> visible classes.  Ie, if the way to create a class that had every type
> as an instance were to make a :- default_class declaration instead of
> a :- class declaration, then changes to the declaration would only
> affect modules in which it was visible.

The problem with default instances that I am referring to can take two
forms:

a) A programmer writes code that intends to use a specific instance, but
then forgets to write the instance or forgets to import it, or the
visibility of the instance is inadvertently changed some time down the
track.  The unintended result is that the generic instance is used
instead.

b) A programmer writes code that intends to use the generic instance,
but somebody later adds a specific instance or causes one to become
visible for an unrelated reason.  The unintended result is that the
specific instance is used instead.

If we were to introduce some form of generic or default instances (and
I'm not yet convinced that we should), then I think we need to help
programmers avoid the above problems.  The fact that the "defaultness"
is necessarily visible does not help to do this.

The best way to achieve this, IMHO, is to require the programmer to
*explicitly* state when they want the generic instance to apply.  They
could do this with some form of "derives" declaration.  And if there
happens to be a specific instance and a derived instance visible at
the same time, this should be an error.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------