instance visibility (was: Re: The base library and GHC 6.10)

[Claus Reinke]

Hi Ian,

>> >   http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8
>> >Do you think that that behaviour is OK?
> I'm not sure from your reply what your answer to this is.
> 
> Is it "I don't know whether I think that that behaviour is OK or not"?

Your example is a variation of the one that opened the ticket,
so no, I do not think this behaviour is OK. But I also think that
the situation is too complex for a straightforward answer, hence
my less-than-straightforward answer, which perhaps I can expand:

(a) it is clearly not ok in Haskell'98 mode (that is the bug)
(b) it seems to be an unavoidable consequence of a feature of 
    Ghc's non-Haskell'98 mode (specifically Ghc's interpretation of
    allow-overlapping-instances) that actual code relies on, so
    one cannot simply change this behaviour in that mode

People starting from viewpoint (a) have completely different
expectations than people starting from viewpoint (b), for the same
example. And that is clearly not good, so:

(c) this issue highlights the need for a better specification, to 
    reduce the confusion
(d) the Ghc feature itself is only a work-around for Haskell's
    limited control over instance visibility. In particular, one cannot
    prevent re-export of instances in Haskell, so Ghc tries to ensure
    that such re-export only hurts those who actually try to use such
    re-exported instances. Haskellers using overlapping instances
    need to know what they are doing anyway, and Haskellers not
    using overlapping instances, but using libraries that use overlapping
    instances, are less likely to run into trouble this way.

Therefore, my recommendation was:

- follow the Haskell'98 report in Haskell'98 mode (solves (a))

- issue a warning whenever a program contains multiple conflicting
    or duplicate instances in non-Haskell'98 mode, so that (a)-people
    don't get hurt by a feature that (b)-people depend on (that warning
    will confuse, but not hurt, third-party users of (b)-people libraries -
    the ones meant to be helped by (d)) [this should be done anyway]

- look for a real solution to instance re-export (that would avoid (b)
    by making (d) superfluous)

- whatever plan is adopted, document it, as it is likely to be different
    from Haskell'98, and confusion (c) can lead to hard to find bugs.
    The new warning should point to this documentation, so that people
    know what they are being warned about.

Is that any clearer?-)

>> Note that I submitted that ticket;-) I think that the behaviour, the 
>> Haskell'98 vs Ghc discrepancy, the comments, and this thread,
>> show that the rules need to be specified carefully and clearly,
> 
> While that would be helpful, I think that the behaviour you are
> interested in only works because it would be expensive to fix it (at
> least, that's how I understand Simon's
>    "So I'm not sure what to do; and the only thing that comes to mind
>    isn't cheap."
> comment), not because of any unclarity.

Well, you could rule out this Ghc feature for any program not using
allow-overlapping-instances, but then you get back to the traditional
problem (a library uses overlapping instances, a library client doesn't;
and the feature is meant to help users who do not want to know which
of their libraries use overlapping instances). You can definitely rule it
out for Haskell'98 programs, but that won't help much.

You could argue that duplicate instances aren't overlapping instances,
but that only introduces another special case, and the issue remains
for overlapping instances. You cannot rule out this behaviour for
overlapping instances, unless you fix instance re-export control first
(that is the reason this behaviour was introduced in the first place).

Simon's "not cheap" fix refers to the effort implied by fixing the issue
for the special case of no-overlapping-instances (same comment,
two paragraphs up).

There is a righteous approach ("this shouldn't happen. forbid it!"),
there is a pragmatic approach ("this does happen. help users somehow!"),
but I don't know of any right approach unless the instance re-export 
control issue is fixed. So I assume fixing that is the right approach!-)

> I'd be interested to see a design that allows for local instances, in a
> way that doesn't cause problems like in the URL above, but as far as I
> know none exist yet.

While this has come up now and then, most recently here

    http://www.haskell.org/pipermail/haskell-prime/2008-May/002601.html
    http://www.haskell.org/pipermail/libraries/2008-September/010623.html

I'm also not aware of a proper design. As I mention in my reply to 
Simon M, there will actually be an implementation of it in ghci if #2182
is fixed, and it doesn't look too difficult to come up with a syntax,
but a proper design would have to look at the theory (does it make
sense to have modular logic over types? my guess is yes; if not, we 
better change Haskell'98 to propagate all instances through the whole
program!) and practical consequences (and those tend to be unexpected;-).

Simon PJ said that fixing #2182 will need some effort. But after that,
perhaps Ghc can experiment with a simple syntax for instance import/
export control (I was thinking of something similar to .hs-boot file syntax,
bare 'instance C t' to permit export/import of any matching instances,
which would rely on being able to hide items that may not exist), so 
that users can help figuring out any of those unwanted consequences 
that are never obvious in theory.

Claus