Overlapping and incoherent instances

[David Terei]

This is great! It's nice to see something finer grain.

We'd of course like to bring Safe Haskell into the picture though! Our
concern with the new design as it stands is the OVERLAPS flag. We'd
prefer it to be eliminated in favor of requiring developers specify
both OVERLAPPABLE and OVERLAPS if that truly is their intention.

# Why?

## Long Version
https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances--a.k.aInstanceSpecificPragmas

## Short Version (kind-of)
The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly
different. Remember, in Safe Haskell we apply a policy of only
allowing instances from a module M compiled with `-XSafe` to overlap
other instances from module M. If it overlaps (and is the most
specific overlap) instances from modules other than M then we don't
allow this to succeed. This is done to ensure that untrusted code
compiled with `-XSafe` can't alter the behavior of existing code, some
of which may be part of the TCB and security critical.

Brining the new finer grained pragmas into the story we get the following:
* OVERLAPPABLE is the programmer communicating that they can be
overlapped, an open instance if you will. We want to relax the above
restriction and allow instances from `-XSafe` modules to overlap
instances from their own module AND instances declared OVERLAPPABLE
that reside in any module.
* OVERLAPPING is the programming simply declaring they may overlap
less specific instances. We want to keep the above restriction for
these instances. That is, a instance I1 from a `-XSafe` module M won't
be able to overlap as the most specific instance, a instance I2 from
another module if I2 is marked as OVERLAPPING.

This distinction enables new encodings in Safe Haskell by allowing
security library authors to distinguish how untrusted code can overlap
their instances. In some way giving them open vs closed instances.

This distinction is subtle and important. Having a pragma OVERLAPS
that implies both glosses over this and will encourage developers to
use this without much thought.

## Safe Inference
We can also safely infer a module that only has OVERLAPPABLE instances
as safe, while ones that contain OVERLAPPING or OVERLAPS instances
must be regarded as unsafe since there is a difference in semantics of
these pragmas under Safe vs Unsafe.

So we also have an advantage if developers are more specific about
what they want, than just defaulting to OVERLAPS.

Cheers,
David

On 29 July 2014 02:11, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Friends
>
> One of GHC’s more widely-used features is overlapping (and sometimes
> incoherent) instances.  The user-manual documentation is here.
>
> The use of overlapping/incoherent instances is controlled by LANGUAGE
> pragmas: OverlappingInstances and IncoherentInstances respectively.
>
> However the overlap/incoherent-ness is a property of the *instance
> declaration* itself, and has been for a long time.  Using LANGUAGE
> OverlappingInstances simply sets the “I am an overlapping instance” flag for
> every instance declaration in that module.
>
> This is a Big Hammer.  It give no clue about *which* particular instances
> the programmer is expecting to be overlapped, nor which are doing the
> overlapping.    It brutally applies to every instance in the module.
> Moreover, when looking at an instance declaration, there is no nearby clue
> that it might be overlapped.  The clue might be in the command line that
> compiles that module!
>
> Iavor has recently implemented per-instance-declaration pragmas, so you can
> say
>
> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>
> instance {-# OVERLAPPING #-} Show [Char] where …
>
> This is much more precise (it affects only those specific instances) and it
> is much clearer (you see it when you see the instance declaration).
>
> This new feature will be in GHC 7.10 and I’m sure you will be happy about
> that.  But I propose also to deprecate the LANGUAGE pragmas
> OverlappingInstances and IncoherentInstances, as way to encourage everyone
> to use the new feature instead of the old big hammer.  The old LANGUAGE
> pragmas will continue to work, of course, for at least another complete
> release cycle.  We could make that two cycles if it was helpful.
>
> However, if you want deprecation-free libraries, it will entail a wave of
> library updates.
>
> This email is just to warn you, and to let you yell if you think this is a
> bad idea.   It would actually not be difficult to retain the old LANGUAGE
> pragmas indefinitely – it just seems wrong not to actively push authors in
> the right direction.
>
> These deprecations of course popped up in the test suite, so I’ve been
> replacing them with per-instance pragmas there too.  Interestingly in some
> cases, when looking for which instances needed the pragmas, I found…none. So
> OverlappingInstances was entirely unnecessary.  Maybe library authors will
> find that too!
>
> Simon
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>