Opened 7 years ago
Closed 15 months ago
#1050 closed bug (fixed)
Using an inferred type as a type signature fails
Reported by: | simonpj | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | ⊥ |
Component: | Compiler (Type checker) | Version: | 6.6 |
Keywords: | Cc: | a.dcolour@… | |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Difficulty: | Unknown |
Test Case: | Blocked By: | ||
Blocking: | Related Tickets: |
Description
See the thread starting here
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011714.html.
Here's a short example:
class C a b where op :: a -> a -- f :: C a b => a -> a f x = op x
It doesn't get much simpler than that! With the type sig, GHC can't see that the (C a b) provided can satisfy the (C a b1) which arises from the call to op. However, without the constraint, GHC simply abstracts over the constrains arising in the RHS, namely (C a b1), and hence infers the type
f :: C a b1 => a -> a
It is extremely undesirable that the inferred type does not work as a type signature, but I don't see how to fix it easily. It doesn't affect many programs, I think; hence low priority
Change History (6)
comment:1 Changed 7 years ago by simonpj
comment:2 Changed 7 years ago by guest
- Cc a.dcolour@… added
I'm interested in the resolution of this. Added to CC.
comment:3 Changed 6 years ago by simonmar
- Architecture changed from Unknown to Unknown/Multiple
comment:4 Changed 6 years ago by simonmar
- Operating System changed from Unknown to Unknown/Multiple
comment:5 Changed 15 months ago by morabbin
- Type of failure set to None/Unknown
Defect still present in GHC 7.6.1, but I'm seeing some oddness in the number of errors presented with multiples:
{-# LANGUAGE MultiParamTypeClasses #-} class C a b where op :: a -> a f1 :: C a b => a -> a f1 x = op x f2 :: C a b => a -> a f2 x = op x
If we give both type signatures, both fail. If we give neither, both fail (albeit with a different error). Leave out only one type signature, and only that function fails to type. Or, more likely, the other failure is not reported.
I have files to attach if deemed worthwhile (no patch, just files that show the four behaviors).
comment:6 Changed 15 months ago by simonpj
- Resolution set to fixed
- Status changed from new to closed
GHC always checks each type signature for ambiguity; if that faile, it just stops, since ambiguous signatures can lead to futher errors. If there are no sigatures, it goes ahead and tries to typecheck both defns, finding an ambiguous inferred type for each.
It's not perfect, but I think it's good enough.
Simon
See also Oleg's message http://www.haskell.org/pipermail/haskell-cafe/2006-December/020538.html