RE: Extension to the FFI to allow macro expansions to be avoided

"Simon Marlow" <[email protected]> Tue, 13 Apr 2004 11:55:47 +0100
Newsgroups gmane.comp.lang.haskell.ffi
Message-ID <3429668D0E777A499EE74A7952C382D101BA7F7A@EUR-MSG-01.europe.corp.microsoft.com>
 
> 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