#7672: boot file entities are sometimes invisible and are not (semantically)
unified with corresponding entities in implementing module
--------------------------------------+-------------------------------------
Reporter: skilpat | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler (Type
checker)
Version: 7.4.2 | Keywords: recursive modules,
boot files, double vision, double vision problem
Os: Linux | Architecture: x86_64 (amd64)
Failure: GHC rejects valid program | Blockedby:
Blocking: | Related:
--------------------------------------+-------------------------------------
Comment(by skilpat):
I must scale back my assessment of the problem somewhat: double vision is
indeed handled, to some extent, by GHC. In particular, a view of a type
from a boot file is treated ''as an equivalent type'' to a view of that
type from the implementation. That's good! But you still cannot
syntactically refer to both views in the same program. That's less good.
As a slight variation to my example with three modules, we make B expose a
function that mentions (the boot file's view of) T. Then in the A
implementation, we check that this function may be successfully applied to
a value of (the local view of) type T. Indeed, GHC accepts all this!
{{{
module A where
data T
}}}
{{{
module B(Decl.T, f) where
import {-# SOURCE #-} qualified A as Decl
f :: Decl.T -> Bool
f _ = True
}}}
{{{
module A where
import qualified B
data T = Z | S T
x = B.f Z
}}}
In the A implementation I'm not ever mentioning the boot file view of T,
B.T. If you try to do so, then GHC rejects the program with the same error
messages as mentioned in the original report. That is, the following
variation on A fails
{{{
module A where
import qualified B
data T = Z | S B.T
x = B.f Z :: B.T
}}}
with two independent errors, one for each reference to B.T:
{{{
A.hs:3:18:
Not in scope: type constructor or class `B.T'
Perhaps you meant `A.T' (line 3)
A.hs:4:16:
Not in scope: type constructor or class `B.T'
Perhaps you meant `A.T' (line 3)
}}}
In light of this example, I retract my statement that GHC fails to solve
the double vision problem! It's unclear, though, to what extent it does
so, as there's still some amount of wackiness.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7672#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
ghc-tickets mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-tickets
