[GHC] #3806: Type checking errors in foreign declarations
reported at wrong locations
GHC
trac at galois.com
Tue Jan 5 03:39:40 EST 2010
#3806: Type checking errors in foreign declarations reported at wrong locations
---------------------------+------------------------------------------------
Reporter: asuffield | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.1
Resolution: invalid | Keywords:
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
---------------------------+------------------------------------------------
Changes (by simonpj):
* status: new => closed
* difficulty: =>
* resolution: => invalid
Comment:
I see your point, but your follow-up remark hits the nail on the head.
It's fine, for example, to say this:
{{{
module M where
import Foo( foo1 )
newtype Blip = MkBlip { foo2 :: CInt }
class Flop a where
foo3 :: a -> IO ()
instance Flop CInt where ...
foreign export ccall foo1 :: CInt -> IO ()
foreign export ccall foo2 :: Blip -> IO ()
foreign export ccall foo3 :: CInt -> IO ()
}}}
All three are fine. See Section 3.4 in
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-100003.
In short, a `foreign export` is not a type signature at all. It's a
''use'' of `foo`.
An alternative design would be:
* `foreign export foo` really is a type signature for `foo`
* A `foreign export foo` must be accompanied by a top-level definition of
`foo` in the same module.
On the whole I think that might be a better design. It would be simpler,
and I don't think the above cases are important in practice. But that
would mean changing the FFI spec.
I'll close the GHC ticket as invalid, but there's a possible discussion to
be had about what the FFI spec should say.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3806#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list