GHC: Ticket #8450: can't match type Bool with (), but shouldn't have to
http://ghc.haskell.org/trac/ghc/ticket/8450
<p>
The following (definitely type-incorrect) file:
</p>
<pre class="wiki">{-# LANGUAGE ScopedTypeVariables #-}
runEffect :: Either Bool r -> r
runEffect = undefined
run :: forall a. a
run = runEffect $ (undefined :: Either a ())
</pre><p>
produces the following error:
</p>
<pre class="wiki">test.hs:7:7:
Couldn't match type `Bool' with `()'
Expected type: a
Actual type: ()
In the expression: runEffect $ (undefined :: Either a ())
In an equation for `run':
run = runEffect $ (undefined :: Either a ())
</pre><p>
This is strange because one of the two types it claims it can't unify (Bool) doesn't appear in either the expected or actual type. Note that removing the ($) gets a different error message that makes it a bit more clear what's going on:
</p>
<pre class="wiki">test.hs:7:18:
Couldn't match type `Bool' with `()'
Expected type: Either Bool a
Actual type: Either a ()
In the first argument of `runEffect', namely
`(undefined :: Either a ())'
In the expression: runEffect (undefined :: Either a ())
In an equation for `run':
run = runEffect (undefined :: Either a ())
</pre><p>
So it seems it's trying to unify Bool and () because it's unifying both a with Bool and a with (); however, the usual comments about rigid type variables aren't there, which makes even this error message a bit confusing.
</p>
en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/8450
Trac 1.0.7carterThu, 17 Oct 2013 00:25:44 GMT
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:1
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:1
<p>
I hit this problem or something very very close to it, earlier this week. Though in my case it was for type correct code that i had to hoist out as a top level definition to type check.. I'll see if i can repro it in a smaller example.
</p>
TicketsimonpjThu, 17 Oct 2013 15:10:03 GMTcc set
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:2
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:2
<ul>
<li><strong>cc</strong>
<em>dimitris@…</em> added
</li>
</ul>
<p>
Nice example. (The rest of this is cryptic comments mainly for Dimitrios.)
</p>
<p>
The issue is this. We have a skolem 'a', and two constraints
</p>
<pre class="wiki"> [w} a ~ Bool
[w] a ~ ()
</pre><p>
But because we rewrite wanteds with wanteds, we rewrite to
</p>
<pre class="wiki"> [w] Bool ~ ()
</pre><p>
which is really quite unhelpful.
</p>
<p>
I'm beginning to wonder: what would happen if we never rewrote a wanted with another wanted?
</p>
TicketSimon Peyton Jones <simonpj@…>Wed, 06 Nov 2013 09:42:40 GMT
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:3
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:3
<p>
In <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/06aac68dee100b21dc7d304fa90d9baa423507a0/ghc" title="Refactor the constraint solver (again!)
There are three core changes ...">06aac68dee100b21dc7d304fa90d9baa423507a0/ghc</a>:
</p>
<pre class="message">Refactor the constraint solver (again!)
There are three core changes here:
a) In the constraint-solver pipeline.
Given a work-item 'wi', the old scheme was:
let relevant = getRelevantInerts wi
interact 'wi' with each constraint in 'relevant'
Bu now we have a single step
interact 'wi' with the inert-set
This turns out to avoid duplication, between getRelevantInerts
(which needs to know which are relevant) and the interact step.
Simpler, cleaner.
This in turn made it sensible to combine the 'spontaneous solve'
stage into the 'interact with inerts' stage.
b) Wanteds are no longer used to rewrite wanteds. See Trac #8450.
This in turn means that the inert set may have
- many CFunEqCans with the same LHS
- many CTyEqCans with the same LHS
Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs
c) Some refactoring of the representation of the inert set,
Notably inert_dicts and inert_funeqs are indexed by Class and TyCon
respectively, so we can easily get all the constraints relevant to
that class or tycon
There are many knock on effects! This started as a small job but I
ended up doing qite a lot. Some error messages in the test suite
really did improve as a result of (b)</pre>
TicketSimon Peyton Jones <simonpj@…>Wed, 06 Nov 2013 09:46:55 GMT
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:4
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:4
<p>
In <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/8c88d0a9b205a31b1708a7069c4aa417373f9ac3/testsuite" title="Test Trac #8450">8c88d0a9b205a31b1708a7069c4aa417373f9ac3/testsuite</a>:
</p>
<pre class="message">Test Trac #8450</pre>
TicketsimonpjWed, 06 Nov 2013 09:47:44 GMTstatus changed; testcase, resolution set
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:5
http://ghc.haskell.org/trac/ghc/ticket/8450#comment:5
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>testcase</strong>
set to <em>typecheck/should_fail/T8450</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
Thank you for the provocation. Things are much better now.
</p>
<p>
Simon
</p>
Ticket