#5610: Improve "Unacceptable argument type in foreign declaration" error message
----------------------------------------+-----------------------------------
Reporter: bgamari | Owner: simonmar
Type: bug | Status: closed
Priority: high | Milestone: 7.4.1
Component: Compiler (Type checker) | Version: 7.3
Resolution: fixed | Keywords: zlib
Os: Linux | Architecture: x86_64 (amd64)
Failure: GHC rejects valid program | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
----------------------------------------+-----------------------------------
Changes (by Lemming):
* cc: ghc@… (added)
* failure: None/Unknown => GHC rejects valid program
* component: libraries (other) => Compiler (Type checker)
Comment:
Maybe that's not the right place to report my problem ...
Let me summarize:
GHC-6.12 accepted foreign imports containing CInt and similar types
without having access to the CInt constructor. The CInt constructor was
even not exported by Foreign.C.Types.
In contrast to that, GHC-7.4 expects that the CInt constructor is in scope
and it is now also exported by Foreign.C.Types.
I have several places where I wrap around CInt like this:
{{{newtype Counter = Counter CInt}}}.
Consider a module where I use Counter in a foreign call declaration:
{{{
module M where
import A (Counter)
foreign import ccall "c_func" func :: IO Counter
}}}
This would work with GHC-6.12.
However GHC-7.4 not only requires me to import the Counter constructor,
but also the CInt constructor.
This is formally correct but becomes annoying, because CInt is not used
explicitly in M.
Thus in GHC-6.12 I get "unused import" warnings that I can only avoid by
dummy uses
like {{{_dummy :: C.CInt; _dummy = undefined}}}.
In GHC-7.4 I do not get these warnings because the CInt constructor is
used implicitly.
I wonder whether the requirement for importing the constructor can be
dropped, when instead arguments and results of foreign functions must be
in a type class like Storable. We may call it Foreign. Then instead of
importing constructors explicitly, the packing and unpacking would be
encoded in an instance of Foreign and this instance would be imported
automatically. This type class could be automatically derivable for
newtypes and would otherwise enable the user to write instances for
sophisticated types.
This is currently for me an issue because I try to write code that can be
compiled without warnings from GHC-6.12 to GHC-7.4. Maybe there are other
good reasons to use a type class instead of implicit unwrapping and
wrapping of arguments to foreign functions.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5610#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
