[GHC] #11506: uType_defer can defer too long
GHC
ghc-devs at haskell.org
Thu Jan 28 21:47:21 UTC 2016
#11506: uType_defer can defer too long
-------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
It's more than solver engineering.
A pretty fundamental assumption is that a user-writen type signature (at
least one without wildcards) specifies a ''fully-defined'' type. No
unification variables; a fully defined type. Not necessarily closed; e.g.
here the type sig for 'g' is fully defined although it mentions 'a':
{{{
f :: forall a. blah
f x = let g :: a -> a
g x = x
in ...
}}}
But pattern signatures threaten this happy story. They bring into scope a
type variable as a name for a type that may not yet be fully defined, and
certainly isn't here. Much simpler situations can do this too:
{{{
f (x::a, b) = let g :: a -> a
g = ...
in ...
}}}
Here `a` will end up being the name of a unification variable.
This hasn't caused trouble before, but now it is. If we switched off on-
the-fly unification, and did everything in the solver, I bet a lot more
instances would pop up.
What's irritating is that the ability to name unification variables (or
type variables with as-yet-unknown kinds) is not really sought. It's just
hard to exclude.
One possible solution would be to make pattern signatures do matching (not
unification) with the "expected" type, and then insist that the scoped
type variable matched a skolem.
Another would be to treat type variables bound in this way more like
wildards. If we have
{{{
f :: _ -> Maybe _
or
<expression> :: _ -> Int
}}}
then we use ''inference'' not checking, and simply use the signature as a
"shape" against which the inferred type is matched. So a type signature
with any wildcards is NOT treated as a fully defined type. Maybe a type
signature with a free type variable bound by a pattern signature should be
treated similarly. The machinery to do so is all there now.
Uggle. I doubt I'll get to this quickly.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11506#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list