
Could it be considered a bug when a function compiles fine without type signature, but when you add the type signature that GHCi reports with :type, it fails to compile? I am using functional dependencies, and I know these are not the best way to do it. Can all functional dependencies be completely replaced with associated types when using GHC 6.10.1? I tried once but I failed.

Peter Verswyvelen wrote:
Could it be considered a bug when a function compiles fine without type signature, but when you add the type signature that GHCi reports with :type, it fails to compile?
Can you share with us your function and the compiler error, or a small test case and the compiler error? Groetjes, Martijn.

Ouch, how silly of me, I did not make a backup and have been fiddling with the code and now it works. Next time I make sure I'll make backup, sorry about that. On Fri, Feb 13, 2009 at 5:45 PM, Martijn van Steenbergen < martijn@van.steenbergen.nl> wrote:
Peter Verswyvelen wrote:
Could it be considered a bug when a function compiles fine without type signature, but when you add the type signature that GHCi reports with :type, it fails to compile?
Can you share with us your function and the compiler error, or a small test case and the compiler error?
Groetjes,
Martijn.

Peter Verswyvelen wrote:
Could it be considered a bug when a function compiles fine without type signature, but when you add the type signature that GHCi reports with :type, it fails to compile?
There are such cases where it is not a bug. For example, given import Data.Map (fromList) x a = fromList a ghci will happily report that x has type Ord k => [(k, a)] -> Data.Map.Map k a but the name Data.Map.Map is not in scope in the module. Tillmann

No the error I got was
Could not deduce (Controller m v c)
from the context (Controller m v c2)
arising from a use of `MVC' at NM8\GUI\PanZoom.hs:126:32-65
Possible fix:
add (Controller m v c) to the context of the constructor `MVC'
In the expression: MVC m v (PZC s z (unsafeCoerce c))
In the definition of `panZoomedMVC'':
panZoomedMVC' s z (MVC m v c) = MVC m v (PZC s z (unsafeCoerce c))
I got this after adding the type signature of
panZoomedMVC' :: (Controller m v c, PanZoomable z) =>
State -> z -> MVC m v -> MVC m v
But I don't have the problematic code anymore.
Anyway, I've hacking away here, as you can see from the unsafeCoerce call,
which is now not needed anymore ;)
On Fri, Feb 13, 2009 at 6:26 PM, Tillmann Rendel
Peter Verswyvelen wrote:
Could it be considered a bug when a function compiles fine without type signature, but when you add the type signature that GHCi reports with :type, it fails to compile?
There are such cases where it is not a bug. For example, given
import Data.Map (fromList)
x a = fromList a
ghci will happily report that x has type
Ord k => [(k, a)] -> Data.Map.Map k a
but the name Data.Map.Map is not in scope in the module.
Tillmann

2009/2/13 Peter Verswyvelen
No the error I got was Could not deduce (Controller m v c) from the context (Controller m v c2) arising from a use of `MVC' at NM8\GUI\PanZoom.hs:126:32-65 Possible fix: add (Controller m v c) to the context of the constructor `MVC' In the expression: MVC m v (PZC s z (unsafeCoerce c)) In the definition of `panZoomedMVC'': panZoomedMVC' s z (MVC m v c) = MVC m v (PZC s z (unsafeCoerce c)) I got this after adding the type signature of panZoomedMVC' :: (Controller m v c, PanZoomable z) => State -> z -> MVC m v -> MVC m v
No function with the type signature of panZoomedMVC' can be called (unless there is a functional dependency that uniquely determines c from m and v). It's ambiguous; there's no way to know which instance to call. GHC allows such a function to get an inferred type, but then when it comes time to call it (and provide the Controller instance) or type check it against a provided signature, it cannot resolve the ambiguity and you get that error. What is happening in this case is something along these lines: 1) Infer a type and constraints for panZoomedMVC': Constraints: Controller t1 t2 t3 PanZoomable t4 Type: State -> t4 -> MVC t1 t2 -> MVC t1 t2 2) Unify the inferred type signature with your provided signature Constraints: Controller m v t3 PanZoomable z Type: State -> z -> MVC m v -> MVC m v 3) Verify that constraints are sufficient. This fails, because the use of Controller in the function (Controller m v t3) doesn't match the use provided by your constraint (Controller m v c). However, leaving out the type signature doesn't help you; it just delays your problem. Because of the ambiguity, panZoomedMVC' cannot be called; you'll get the error at the callsite instead. To solve this problem, either add a dummy argument that fixes "c", or add a functional dependency or associated type to Controller that fixes c based on m and v. For example:
data Proxy a = Proxy panZoomedMVC' :: (Controller m v c, PanZoomable z) => Proxy c -> State -> z -> MVC m v -> MVC m v panZoomedMVC' _ s z mvc = ...
Then you can pass the proper "Proxy" when calling the function to make the typechecker happy. or
class Controller m v c | m v -> c where ...
or
class Controller m v where type Control m v ...
-- ryan

Thanks Ryan.
I'm always struggling with functional dependencies since to be honest - I
don't really understand how the type inferer figures out all the types and I
didn't take the time to study it yet. Your email will help me a bit further
with this.
My functional dependency was c -> m v. It can't be m v -> c since for the
same model and view type , you can have many controllers types.
On Sat, Feb 14, 2009 at 11:38 PM, Ryan Ingram
2009/2/13 Peter Verswyvelen
: No the error I got was Could not deduce (Controller m v c) from the context (Controller m v c2) arising from a use of `MVC' at NM8\GUI\PanZoom.hs:126:32-65 Possible fix: add (Controller m v c) to the context of the constructor `MVC' In the expression: MVC m v (PZC s z (unsafeCoerce c)) In the definition of `panZoomedMVC'': panZoomedMVC' s z (MVC m v c) = MVC m v (PZC s z (unsafeCoerce c)) I got this after adding the type signature of panZoomedMVC' :: (Controller m v c, PanZoomable z) => State -> z -> MVC m v -> MVC m v
No function with the type signature of panZoomedMVC' can be called (unless there is a functional dependency that uniquely determines c from m and v). It's ambiguous; there's no way to know which instance to call.
GHC allows such a function to get an inferred type, but then when it comes time to call it (and provide the Controller instance) or type check it against a provided signature, it cannot resolve the ambiguity and you get that error.
What is happening in this case is something along these lines:
1) Infer a type and constraints for panZoomedMVC':
Constraints: Controller t1 t2 t3 PanZoomable t4
Type: State -> t4 -> MVC t1 t2 -> MVC t1 t2
2) Unify the inferred type signature with your provided signature
Constraints: Controller m v t3 PanZoomable z
Type: State -> z -> MVC m v -> MVC m v
3) Verify that constraints are sufficient. This fails, because the use of Controller in the function (Controller m v t3) doesn't match the use provided by your constraint (Controller m v c).
However, leaving out the type signature doesn't help you; it just delays your problem. Because of the ambiguity, panZoomedMVC' cannot be called; you'll get the error at the callsite instead.
To solve this problem, either add a dummy argument that fixes "c", or add a functional dependency or associated type to Controller that fixes c based on m and v. For example:
data Proxy a = Proxy panZoomedMVC' :: (Controller m v c, PanZoomable z) => Proxy c -> State -> z -> MVC m v -> MVC m v panZoomedMVC' _ s z mvc = ...
Then you can pass the proper "Proxy" when calling the function to make the typechecker happy.
or
class Controller m v c | m v -> c where ...
or
class Controller m v where type Control m v ...
-- ryan

Am Freitag, 13. Februar 2009 17:16 schrieb Peter Verswyvelen:
Can all functional dependencies be completely replaced with associated types when using GHC 6.10.1?
It might be possible as long as you don’t use overlapping instances. With overlapping instances, it’s typically not possible since there are no overlapping type family instances. Best wishes, Wolfgang
participants (5)
-
Martijn van Steenbergen
-
Peter Verswyvelen
-
Ryan Ingram
-
Tillmann Rendel
-
Wolfgang Jeltsch