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.

Cheers,
	Simon


More information about the FFI mailing list