Unexpected "no such instance" messages

George, Sergey

Both of you recently tripped over a subtle consequence of a change I
made 
to the way that GHC handles restricted (monomorphic) bindings.  In both
cases,
the program offered two ways to solve some type-class constraints; my
change
caused GHC to solve the constraints differently.   That led to type
errors when
your type signatures no longer worked.  (I enclose the relevant message
wrt
George; Sergey is very recent, so he'll know.)

So I have revisited my original change. It was motivated by another,
unrelated, 
consequence of 'improvement'.   However, after some thought I was able
to solve
that problem differently, so your programs should work again (in the
HEAD anyway;
I will think about transplanting the change back to the branch).


Haskell's monomorphism restriction is truly gruesome. The primary source
of the
trouble is the term "the constrained type variables" in the boxed
definition
of the MR on page 64 of the Report.  In the presence of all the GHC
extensions,
it's far from clear what these "constrained type variables are".

Anyway, bottom line: I think you'll be happy now.

Simon
 



| -----Original Message-----
| From: glasgow-haskell-bugs-bounces@xxxxxxxxxxx
[mailto:glasgow-haskell-bugs-
| bounces@xxxxxxxxxxx] On Behalf Of Simon Peyton-Jones
| Sent: 31 March 2004 14:27
| To: George Russell; glasgow-haskell-bugs@xxxxxxxxxxx
| Subject: RE: Possible instances problem with ghc-6.2.1
| 
| George
| 
| This "bug" is the same as the one I described in the enclosed message,
| but it's a bit simpler this time.
| 
| The basic setup is:
| 
| newFormEntry :: HasButton value => Radio value -> Int
| instance Show value => HasButton value
| 
| foogle :: (HasButton woggle) => Radio woggle -> Int
| foogle lab = let
|                      form0 = newFormEntry lab
|                in
|                undefined
| 
| The call to newFormEntry requires the constraint (HasButton woggle).
| You point out that (HasButton woggle) is available in foogle's type.
But
| it's *also* available via
|       instance Show value => HasButton value
| So it depends on which of two (incompatible!) ways of deriving
| (HasButton woggle) wins.  GHC makes no guarantees about this.
| 
| In fact, a recent change (don't ask) makes GHC just a bit keener to do
| context simplification at monomorphic local definitions (like that for
| form0).  So GHC tries to simplify the (HasButton woggle) constraint at
| the "form0 = ..." point, and succeeds by using the instance
declaration.
| 
| 
| 
| In short, you'd defined a non-confluent rewrite system, so you should
| not be surprised if it unpredictably paints you into a corner, and
does
| so differently on different days of the week.
| 
| Simon
| 
| 
| | -----Original Message-----
| | From: glasgow-haskell-bugs-bounces@xxxxxxxxxxx
| [mailto:glasgow-haskell-bugs-
| | bounces@xxxxxxxxxxx] On Behalf Of George Russell
| | Sent: 26 March 2004 10:21
| | To: glasgow-haskell-bugs@xxxxxxxxxxx
| | Subject: Possible instances problem with ghc-6.2.1
| |
| | With ghc-6.2.1 compiled from source
| |
| | tar -xzf instances2.tar.gz
| | cd instances2
| | gmake
| |
| | produces the message:
| |
| | AttributesType.hs:15:
| |      Could not deduce (Show value)
| |     from the context (AttributeValue (Radio value),
| |                       HasConfigRadioButton value,
| |                       Bounded value,
| |                       Enum value,
| |                       FormLabel label)
| |        arising from use of `newFormEntry' at AttributesType.hs:15
| |
| |
| |
| | However:
| | (1) this does not seem to happen with ghc-6.2.
| | (2) why does newFormEntry need Show anyway?  It would only be
| | relevant in deducing HasConfigRadioButton, but in fact
| | it has that in the context anyway.
| |
| |
| | Sorry I didn't report this earlier.