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
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
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 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
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
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
> 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. [...]
>
> I definitely support Fergus' point of vie
Fergus Henderson wrote:
[...] I the right way to solve this is to support some way for the Haskell
user to tell the Haskell implementation what the right type is, for example
perhaps something along the lines of
data WINDOW
foreign import ccall unsafe "static curses.h wstandend" wstandend
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. [...]
I definitely support Fergus' point of view, GHC and Hugs really rush
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 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 aroun
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 sy
On 08-Apr-2004, Alastair Reid <[EMAIL PROTECTED]> 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
> cle
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 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 function name as Ian originally suggested?
It would also s
> 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
> t
> 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
>
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
>
> 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
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.netâjohnâ
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskel
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
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 extr
22 matches
Mail list logo
