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: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of George Russell
| Sent: 26 March 2004 10:21
| To: [EMAIL PROTECTED]
| 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.
---BeginMessage---
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of George Russell
| Sent: 18 March 2004 14:30
| To: [EMAIL PROTECTED]
| 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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
---End Message---
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
