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
Sven Panne <[EMAIL PROTECTED]> writes:
> Fergus Henderson wrote:
> > [...] the Haskell FFI has sacrificed quality for easy of implementation.
> > If this starts causing problems for users, I think the right solution
> > is to raise the bar for implementations, not to lower it. [...]
>
> P.S. to M
W liście 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
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
W liście 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 desire
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 C
