July 2002 - FFI - Haskell.org

RE: Generating Function Prototypes
by Simon Marlow 04 Jul '02

04 Jul '02

> >> Of course, this ignores the detail that while the C compilers are > >> generating correct code, they may also be generating warnings about > >> alleged type errors - which can be a bit disconcerting. > > > It is an error, not just a warning, if the prototypes don't match. > > GCC will complain loudly if there's a missing 'const' - it won't > > generate any code at all. > > Well, if you disable the warning by giving gcc a consistent story, > then the code is correct. (To give gcc a consistent story, don't > #include any user or system-supplied headers and make sure gcc doesn't > silently #include any of its own (as it likes to do).) I don't think it's possible to completely eliminate system headers from the transitive closure of stuff we include when compiling a .hc file. I've just taken a look at this, and it seems that while we can eliminate a lot of the stuff we include, there are some awkward ones: we need gmp.h for Integer operations, and that includes <stddef.h>, and HsFFI.h needs <stdint.h> to get the int-type limits (perhaps these could be autoconf'd). Cheers, Simon

3 3

Re: Generating Function Prototypes
by Ashley Yakeley 04 Jul '02

04 Jul '02

At 2002-07-04 03:55, Alastair Reid wrote: >I still think we're better off removing header files completely and >having the Haskell type completely determine the calling convention >employed. I agree. The Haskell compiler doesn't necessarily need to spit out its own prototypes for the benefit of the C code, but it should be able to compile Haskell without needing the header files. In particular, if I specify this: foreign import ccall "swapHalves" swapHalves :: Int64 -> IO Int64; ...the Haskell compiler ought to call the function as if it returns a "long long" (or other 64-bit signed integer type). -- Ashley Yakeley, Seattle WA

1 0

Generating Function Prototypes
by Ashley Yakeley 04 Jul '02

04 Jul '02

I've been having trouble with an imported function that returns Int64/"long long". Haskell doesn't generate a prototype, so regular 'int' type is assumed. Why doesn't Haskell generate a prototype from the 'foreign import' declaration, as part of the -fvia-C compilation? When the prototype is omitted, a default one is assumed. Surely FFI can improve on the default with the information given by the 'foreign import' declaration? In the mean time, how do I work around the problem and provide a prototype myself? -- Ashley Yakeley, Seattle WA

4 6

Re: HTML Please
by Ashley Yakeley 04 Jul '02

04 Jul '02

At 2002-07-03 17:52, Manuel M. T. Chakravarty wrote: >I recommend to use > > http://freshmeat.net/projects/gv/ > >for PostScript files. Unfortunately I don't have an X11 display either... >If you had had a look at where the error occurs, That counts as porting/debugging work in my book, which I normally don't associate with reading documentation. I really _don't_ want to have to learn TeX without a compelling reason... However, your new PDF is readable. Thanks -- Ashley Yakeley, Seattle WA

1 0

HTML Please
by Ashley Yakeley 04 Jul '02

04 Jul '02

TeX and PostScript are very difficult to deal with if you don't have a printer. I can convert the PS to PDF, but of course TeX has its own font system that generates bitmaps, that end up illegible in Acrobat unless you expand it to around 48pt. Would it be possible to provide addenda to the Report in the same formats the Report itself is available in, or at least something online-friendly? Even plain text wouldn't be so bad. -- Ashley Yakeley, Seattle WA

3 2

RE: Generating Function Prototypes
by Ashley Yakeley 04 Jul '02

04 Jul '02

At 2002-07-03 09:23, Simon Marlow wrote: >> Of course, this ignores the detail that while the C compilers are >> generating correct code, they may also be generating warnings about >> alleged type errors - which can be a bit disconcerting. > >It is an error, not just a warning, if the prototypes don't match. GCC >will complain loudly if there's a missing 'const' - it won't generate >any code at all. For 'foreign import' this won't happen, will it? The Haskell compiler can generate its own prototype as well as the call to the function. The only thing that matters is that the calling conventions for const and non-const pointers are the same... -- Ashley Yakeley, Seattle WA

1 0

Re: Generating Function Prototypes
by Ashley Yakeley 04 Jul '02

04 Jul '02

At 2002-07-03 06:23, Alastair Reid wrote: >Which compiler is this for? As you saw from the other replies, >compilers vary in whether or not they add prototypes. GHC: yes, NHC: >no, Hugs: depends which day you grabbed your copy from CVS. GHC, but it doesn't add a prototype. -- Ashley Yakeley, Seattle WA

1 0

RE: Generating Function Prototypes
by Simon Marlow 04 Jul '02

04 Jul '02

> Of course, this ignores the detail that while the C compilers are > generating correct code, they may also be generating warnings about > alleged type errors - which can be a bit disconcerting. It is an error, not just a warning, if the prototypes don't match. GCC will complain loudly if there's a missing 'const' - it won't generate any code at all. Cheers, Simon

2 1

RE: More C interfacing issues
by Simon Marlow 03 Jul '02

03 Jul '02

> > What's wrong with just doing this in the plain FFI? > > > foreign import ccall "getyx" getyx > > :: Ptr Window -> Ptr CInt -> Ptr CInt -> IO () > > > Have I missed something? > > You need at least one wrapper because getyx is a macro. Note that the > arguments are ints _not_ int*s. Aha! :-) Then I would probably write a C wrapper with the above type. Curious: how does green card know that getxy is a macro and that x and y are out parameters... do you have to tell it? Cheers, Simon

2 1

Re: HTML Please
by George Russell 03 Jul '02

03 Jul '02

I much prefer HTML to PDF, LaTeX or PS. I can set the font size to be comfortable for my eyes while still leaving space on my screen for an XEmacs window. Also you can do text searches of HTML.

1 0