Extension to the FFI to allow macro expansions to be avoided
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