I have a concern with this, if I understand the issue correctly.
Suppose I have a source module that compiles and runs correctly.
Now suppose I add a restricted (selective) import statement to the file, explicitly introducing a name that I know does not clash with anything in my module. I expect the module to continue to compile and run correctly.
If I understand Lennart's proposal correctly, adding such an import could cause the compilation to fail, by adding new instance options that then needs to be disambiguated.
Under the present regime, this is not a problem, because information to disambiguate the instance selection needs to added even if there's only one visible instance, so adding the restricted import cannot introduce this failure.
Similar concerns might apply if new instances are added to a module that is already a restricted import.
I suspect that the proper fix to this is that a selective import should also name the instances that are imported. Then disambiguation of instances can reasonably be based on just the visible imports. The automatic import of instances, even when the restricted form of import is used, has often seemed a little odd to me.
#g --
At 14:36 25/11/04 +0000, Keean Schupke wrote:
I have already asked Simon PJ if this can be implemented in GHC... So if more people
ask for it, it might get done!
Keean
Lennart Augustsson wrote:
Here is a small puzzle.
-- The following generates a type error: f :: Char -> Char f c = let x = g c in h x
-- But this definition does not: f :: Char -> Char f c = let x :: Bool x = g c in h x
Furthermore, replacing Bool by any other type in the latter definition will always give a type error.
How is this possible?
Scroll down for the answer.
Here is the module:
module Puzzle(f) where
f :: Char -> Char f c = let x = g c in h x
class C a where g :: Char -> a h :: a -> Char
instance C Bool where g c = c == 'T' h b = if b then 'T' else 'F'
The error message from ghc is Puzzle.hs:5:12: Ambiguous type variable `a' in the top-level constraint: `C a' arising from use of `g' at Puzzle.hs:5:12
I know the technical reason why this is happening. But it's hard for me to motivate why this is reasonable. The type variable `a' is not ambiguous at all, the only type it can possibly have is Bool; any other type is an error.
Furthermore, there can never be any other instance of the class C added to any program using the module Puzzle since the class C is not exported.
So in what sense is this really ambiguous?
I think it would be quite reasonable to allow the Puzzle module to compile, resolving `a' to be Bool. I.e., if there is only one instance that can satisfy a constraint and there is no possibility of adding instances outside the compiled module, I think resolving the overloading makes sense.
-- Lennart _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
