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

[Alastair Reid]

 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.

Maybe the code generated by Hugs should be something like:

#ifdef MACROS_ARE_COOL
#undef malloc
#endif

?

(I'm not likely to implement this anytime soon but if someone has the energy 
to do so, go right ahead.)

From what I know of NHC, it probably has the same extension and would benefit 
from the same cleanup.

--
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi

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

[Simon Marlow]

 
 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
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi