Extension to the FFI to allow macro expansions to be avoided

Simon Marlow simonmar at microsoft.com
Tue Apr 13 06:55:47 EDT 2004

> On Thu, Apr 08, 2004 at 10:18:24AM +0100, Alastair Reid wrote:
> > Now that I understand the problem, my feeling is that the 
> problem is not with 
> > curses but with GHC's compilation method.  GHC is using a 
> shortcut by 
> > pretending that the ffi is for interfacing to cpp+C whereas 
> the ffi is quite 
> > clear that it is for interfacing to C.  So, I think the 
> thing to do is fix 
> > GHC.
> And Hugs too.  The issue isn't extending the FFI but implementing it
> more accurately and consistently.  As you point out, systems compiling
> via C have been extending the FFI to a function+macro 
> interface, which is
> incompatible with systems compiling to native code.  Having 
> been bitten by
> the same thing in the opposite direction (macros that work 
> with ffihugs
> or ghc -fvia-C don't work with ghc -fasm), I'd favour turning off the
> macro interface, preferably with #undef, at least by default.

Agreed.  Why is #undef to be preferred over adding parentheses around
the function name as Ian originally suggested?

Contrary to what I first thought, disabling the use of macros in FFI
calls should have no impact on GHC, so I'm happy to make this change.


More information about the FFI mailing list