> original, "g" is actually a method in a class, and its definition is in
> an instance declaration. Its type is actually given, not annotated. For
> instance:
>
Ah, g is meant to be a method. Well, ...
> -- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
> module Weir
On Tuesday, Sep 9, 2003, at 00:40 US/Pacific, Martin Sulzmann wrote:
Your type annotation
g :: (F a b,D b (T r)) => (a,T r)
g = f
is simply incorrect.
I must say I don't understand. I need a value of that type. In the
original, "g" is actually a method in a class, and its definition is in
an in
Simon said
> This is a tricky one. Here's what is going on.
I believe there's nothing tricky going on.
Your type annotation
g :: (F a b,D b (T r)) => (a,T r)
g = f
is simply incorrect. Keep in mind that GHC does NOT improve
type annotations. For example,
g :: (F a b, C (T r)) => (a,T r)
g
On Monday, Sep 8, 2003, at 03:53 US/Pacific, Simon Peyton-Jones wrote:
Consider an instance decl like:
instance (Lte a b l,If l b a c) => Max a b c
(This is a real example.) Notice that "l" is used on the LHS of the
=> but not the RHS. The idea is that "l" will get unified by a
functional de
lasses
undecidable instances
functional dependencies
type sigs with non-simple contexts
makes it difficult to design a confluent solver. Martin S may have
ideas about what restrictions would make it confluent.
Simon
| -Original Message-----
| From: [EMAIL PROTECTED]
[m
This fails to compile. Oddly enough, if you remove the instance
declaration (1), or if you remove the r parameter to T, or if you do any
of the other simplifications I've tried, it compiles successfully.
-- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
module WeirdInsts where
