In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest
#8650: Unexpected behaviour of import ccall "header.h function" -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Basically, by providing the correct header file in the import specification, you gain portability to Haskell compilers which compile via C (including, but not limited to, ancient or unregisterised versions of GHC). Replying to [ticket:8650 nh2]: this if the {{{"string.h"}}} part is ignored? Because that is the Haskell 2010 Report, not the GHC documentation (though it would be accurate for unregisterised versions of GHC).
Relatedly, I can write
{{{ foreign import ccall "some.rubbish" f :: IO ... }}}
and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain.
As specified by section 8.5.1 of the Report, both the `chname` and the `cid` are optional. The Report does not specify how to resolve the resulting ambiguity, but since a C identifier cannot contain a dot, GHC must be treating `some.rubbish` as the header file name, and using the Haskell name `f` as the C identifier, as also specified by the Report:
If `cid` is omitted, it defaults to the name of the imported Haskell variable.
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8650#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler