GHC: Ticket #12703: Expand Backpack's signature matching relation beyond definitional equality
http://ghc.haskell.org/trac/ghc/ticket/12703
<p>
Currently, signature matching is done by strict definitional equality. This can be pretty inconvenient in some cases (it is also the only place in the Haskell language that we actually expose definitional equality):
</p>
<p>
<strong>Polymorphism.</strong> This is the obvious one. If I have an implementing function that is more polymorphic than my signature, I have to manually monomorphize it.
</p>
<pre class="wiki">unit p where
signature H where
import Prelude (Int)
data String
length :: String -> Int
unit q where
module H(String, length) where
-- from Prelude
unit r where
dependency p[H=q:H]
</pre><p>
Gives
</p>
<pre class="wiki"><no location info>: error:
Identifier ‘Data.Foldable.length’ has conflicting definitions in the module
and its hsig file
Main module: Data.Foldable.length ::
Data.Foldable.Foldable t => forall a. t a -> GHC.Types.Int
Hsig file: Data.Foldable.length ::
GHC.Base.String -> GHC.Types.Int
The two types are different
</pre><p>
Essentially, you have to monomorphize any functions you want to use. Annoying!
</p>
<p>
One particular place this shows up is if you're incrementally Backpack'ing an interface that has an existing type class. In this case, you might like to just reexport the methods of the type class and "fill" the imports; but these methods have the wrong types! (They're not monomorphic enough).
</p>
<p>
<strong>Quantifier ordering.</strong> Here's a more subtle one: if I don't explicitly specify a type signature, GHC will pick whatever quantifier ordering it wants. Quantifier ordering affects definitional equality.
</p>
<p>
It's actually pretty easy to trigger this, since GHC seems to always pick the reverse of what you'd get if you explicitly specified the type signature:
</p>
<pre class="wiki">unit p where
signature H where
k :: a -> b -> a
unit q where
module H where
k x y = x
unit r where
dependency p[H=q:H]
</pre><p>
Fails with:
</p>
<pre class="wiki">q.bkp:7:9: error:
Identifier ‘q:H.k’ has conflicting definitions in the module
and its hsig file
Main module: q:H.k :: t2 -> t1 -> t2
Hsig file: q:H.k :: a -> b -> a
The two types are different
</pre><p>
<strong>Constraint relaxation.</strong> In <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/12679" title="#12679: feature request: Permit abstract data types in signatures that don't have kind * (closed: fixed)">#12679</a>, you might want to define an abstract class which you can use to let implementors pass in type class instances that they might need. But you often end up in situations where the real implementations of your functions require less constraint than the signature specifies; for example, you might write <code>insert :: Key k => k -> a -> Map k a -> Map k a</code>, but if Map is an association list and just appends the new value onto the front of the list, no Eq constraint needed! There goes another impedance matching binding.
</p>
<p>
<strong>Type families.</strong> Type family applications aren't reduced when deciding definitional equality.
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
unit p where
signature H where
f :: Int
unit q where
module H where
type family F
type instance F = Int
f :: F
f = 2
unit r where
dependency p[H=q:H]
</pre><p>
Gives
</p>
<pre class="wiki">q.bkp:11:9: error:
Identifier ‘q:H.f’ has conflicting definitions in the module
and its hsig file
Main module: q:H.f :: q:H.F
Hsig file: q:H.f :: GHC.Types.Int
The two types are different
</pre><p>
<strong>Discussion.</strong> It's instructive to consider what the impacts of this sort of relaxation would have on hs-boot files. Some of the equalities that users expect in the source language have operational impact: for example, the ordering of constraints affects the calling convention of the function in question. So there would need to be an impedance matching binding to reorder/drop constraints to match the defining function. We already do an impedance matching of this sort with dictionary functions; this would be a logical extension. Thus, a signature would have to monomorphize, coerce, etc--whatever it needs to show the matching holds. I think this is quite plausible, although it would require rewriting this chunk of code.
</p>
en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/12703
Trac 1.2.2ezyangFri, 10 Feb 2017 09:04:12 GMTdescription changed
http://ghc.haskell.org/trac/ghc/ticket/12703#comment:1
http://ghc.haskell.org/trac/ghc/ticket/12703#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/trac/ghc/ticket/12703?action=diff&version=1">diff</a>)
</li>
</ul>
TicketezyangWed, 01 Mar 2017 19:26:44 GMT
http://ghc.haskell.org/trac/ghc/ticket/12703#comment:2
http://ghc.haskell.org/trac/ghc/ticket/12703#comment:2
<p>
One of the main technical challenges is extending our declaration merging operation to handle any such subtyping relation.
</p>
Ticket