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