[Haskell] A puzzle and an annoying feature

[Graham Klyne]

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
>>Haskell at haskell.org
>>http://www.haskell.org/mailman/listinfo/haskell
>
>
>_______________________________________________
>Haskell mailing list
>Haskell at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact