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.

--- Begin Message ---

Subject:	RE: Problem deriving instances

You are playing fast and loose here.

instance (HasBinary ty IO) => HasCodedValue ty

doDecodeIO :: HasCodedValue a => () -> () -> IO a
doDecodeIO codedValue view =
let
act = doDecodeIO1 "foo" codedValue view
in
act

doDecodeIO1 :: HasCodedValue a => String -> () -> () -> IO a
doDecodeIO1 desc icsl view = error "foo"


The call to doDecodeIO1 gives rise to a constraint (HasCodedValue t).
GHC is reducing the constraint using the instance declaration, to the
constraint (HasBinary ty IO). That in turn can be reduced, and ends up
needing HasWrapper.

So in effect you have provided *two* ways for GHC to satisfy the
constraint (HasCodedValue t) -- first, by the instance decl, and second
by the (HasCodedValue a) constraint on doDecodeIO. This is a Very Bad
Idea. They overlap with no way to pick one rather than the other.

Why has the behaviour changed? Because I fixed a bug concerning
functional dependencies a couple of days ago, whose fix requires us to
be a bit more brutal about simplifying constraints for monomorphic
bindings such as that of 'act'. To see why, look at the comments with
TcSimplify.tcSimplifyRestricted.

In general, instances that look like
instance .. => Cls a
are deeply suspicious. They overlap with absolutely everything.

Simon

| -----Original Message-----
| From: cvs-all-bounces@xxxxxxxxxxx [mailto:cvs-all-bounces@xxxxxxxxxxx]
On Behalf Of George Russell
| Sent: 18 March 2004 14:30
| To: cvs-ghc@xxxxxxxxxxx
| Subject: Problem deriving instances
|
| With GHC compiled and downloaded from the read-only repository this
morning:
|
| tar -xzf instances.tar.gz
| cd instances
| make
|
| produces the error
|
| CodedValue.hs:14:12:
| Could not deduce (HasWrapper a IO) from the context
(HasCodedValue a)
| arising from use of `doDecodeIO1' at CodedValue.hs:14:12-22
| Probable fix:
| Add (HasWrapper a IO) to the type signature(s) for `doDecodeIO'
| Or add an instance declaration for (HasWrapper a IO)
| In the definition of `act': act = doDecodeIO1 "foo" codedValue
view
| In the definition of `doDecodeIO':
| doDecodeIO codedValue view = let act = doDecodeIO1 "foo"
codedValue view in act
|
| but for earlier GHCs, for example 6.2, it works. What is going on?
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/cvs-ghc

--- End Message ---

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs