On 15-Apr-2004, Sven Panne [EMAIL PROTECTED] wrote:
Fergus Henderson wrote:
I'd rather fix GHC so that interfacing with C macros works with ghc -fasm.
The equivalent works fine with the Mercury implementation (mmc --target
asm
generates assembler for the Mercury code and C stubs for the FFI
W licie z czw, 15-04-2004, godz. 18:14 -0700, Fergus Henderson napisa:
When using the --target asm option, which tells the Mercury compiler to
compile directly to assembler, the Mercury compiler will generate some
C glue code to handle the FFI interfacing pragmas.
Which - in case it's a plain
On 16 April 2004 11:33, Marcin 'Qrczak' Kowalczyk wrote:
Perhaps we should differentiate by a calling convention between
linking to a function directly and generating a source-level C call?
The calling conventions we know would correspond to linking to them
directly. They would perform the
W licie z pi, 16-04-2004, godz. 15:25 +0100, Simon Marlow napisa:
I wondered about that (while writing my last post) but it still seems
like a hefty price to pay for the small number of problematic cases we
have, and given that you can already write the C stubs by hand to get
the desired
I really like that the Haskell FFI is defined at the ABI level, and that
it doesn't need to generate its own stub funtions or whatnot. I
especially like that it doesn't require having a C compiler installed.
it is a foreign function interface that supports the C calling
convention. If you want a
Fergus Henderson wrote:
I'd rather fix GHC so that interfacing with C macros works with ghc -fasm.
The equivalent works fine with the Mercury implementation (mmc --target asm
generates assembler for the Mercury code and C stubs for the FFI glue),
so it's clearly possible.
How does Mercury handle
On 08-Apr-2004, Ian Lynagh [EMAIL PROTECTED] wrote:
The problem
===
Some C libraries (curses is the one I have to hand) provide macros in
addition to functions in some cases for efficiency reasons.
That is a feature, not a problem. And it is not just for efficiency reasons.
On 13-Apr-2004, Ross Paterson [EMAIL PROTECTED] wrote:
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
On 13-Apr-2004, Ross Paterson [EMAIL PROTECTED] wrote:
On Tue, Apr 13, 2004 at 11:55:47AM +0100, Simon Marlow wrote:
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
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
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
Alastair Reid wrote:
[...] where the decision to insert parens is decided by a
command-line flag. [...]
I'm still not convinced that any change is really necessary,
but I'd really
prefer a command-line flag over a change in the FFI syntax.
The latter will
lead to much more
Ian Lynagh writes:
Some C libraries (curses is the one I have to hand) provide macros in
addition to functions in some cases for efficiency reasons. If you use
the FFI to import such a function thus:
I was a bit confused by what Ian meant by this so, in case it helps others,
here's an
Alastair Reid wrote:
[...] where the decision to insert parens is decided by a command-line flag. [...]
I'm still not convinced that any change is really necessary, but I'd really
prefer a command-line flag over a change in the FFI syntax. The latter will
lead to much more portability trouble than
This is exactly the problem I ran into when using the FFI to interface
with curses. I just created a my_curses.h with appropriate #undefs in
it.
John
--
John Meacham - repetae.netjohn
___
FFI mailing list
[EMAIL PROTECTED]
[This has come from the cvs-ghc list. All the info should be in this
mail, though].
The problem
===
Some C libraries (curses is the one I have to hand) provide macros in
addition to functions in some cases for efficiency reasons. If you use
the FFI to import such a function thus:
-
16 matches
Mail list logo
