Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
On Fri, 2007-12-21 at 10:25 +0100, Gour wrote: On Thu, 20 Dec 2007 03:41:21 + Duncan Coutts [EMAIL PROTECTED] wrote: In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. It looks that c2hs does more than hsc2hs and misses less than hsc2hs. Why not equip c2hs to do the rest and have one complete tool instead of the two uncomplete ones? (I understand that time-factor could be the reason.) The reason hsc2hs does the structure bits well is because it asks the C compiler about the sizes and offsets of field members. This means it is always accurate. For c2hs to do the same it has to calculate the sizes, offsets and alignments of types itself and it requires a lot of work and testing to make sure this is always 100% accurate. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
On Thu, 20 Dec 2007 03:41:21 + Duncan Coutts [EMAIL PROTECTED] wrote: The main advantage of c2hs over hsc2hs is that c2hs generates the correct Haskell types of foreign imports by looking at the C types in the header file. This guarantees cross language type safety for function calls. It also eliminates the need to write foreign imports directly which saves a lot of code. hsc2hs provides no help for writing function imports. The main disadvantage of c2hs compared to hsc2hs is that c2hs's support for marshaling structures is less than stellar while hsc2hs is pretty good at that. In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. It looks that c2hs does more than hsc2hs and misses less than hsc2hs. Why not equip c2hs to do the rest and have one complete tool instead of the two uncomplete ones? (I understand that time-factor could be the reason.) I am for the choice, but there are several library-areas (database binding is one) in Haskell where we could (maybe) apply/strive for less is better slogan ;) Sincerely, Gour ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
stevelihn: On Dec 11, 2007 11:16 PM, Don Stewart [EMAIL PROTECTED] wrote: 2. It offers strong support for integration with other languages and tools (FFI? Is the support strong?) 2. The FFI in Haskell is perhaps the most powerful out there. You can import C or export Haskell to C with a single line FFI decl. Don, I am a newbie on FFI, but have been interested in looking into it. If I google on haskell FFI, what I find is typically: 1. The official Haskell 98 FFI 1.0 2. The FFI preprocessor -- greencard on haskell.org, where several other preprocessors are listed (in the Link section): HaskellDirect, C to Haskell, hsc2hs (included in GHC distributions), QForeign, KDirect. Right. Most of those are out of date. The FFI 1.0 API is certainly the most robust tool. However, the existence of preprocessors seem to suggest (at least very enticing) that the use of a preprocessor would make life easier. Yes, that's the foundation. But when I dig deeper, several of them have not had any release in (more than) 3 years. The only exception seem to be C to Haskell, which is part of gtk2hs, and hsc2hs, being part of GHC. It immediately becomes confusing which tool I should use if I were to work on a FFI project... Can you shed some light on this? There are three approaches, depending on the size of your project. Write your ow FFI decls manually. - Good when you have a small job - and the C types are simple - example: strlen Use hsc2hs: - good for more complex C code. Scales nicely. But a bit tedious. - examples: pcre.h X11.h Use c2hs: - more automated than hsc2hs - less common - scriptable - examples: gtk2hs I use hsc2hs mostly. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
On Wed, 2007-12-19 at 19:07 -0800, Don Stewart wrote: There are three approaches, depending on the size of your project. Write your ow FFI decls manually. - Good when you have a small job - and the C types are simple - example: strlen Use hsc2hs: - good for more complex C code. Scales nicely. But a bit tedious. - examples: pcre.h X11.h Use c2hs: - more automated than hsc2hs - less common The latest version is available on hackage :-) - scriptable - examples: gtk2hs I use hsc2hs mostly. The main advantage of c2hs over hsc2hs is that c2hs generates the correct Haskell types of foreign imports by looking at the C types in the header file. This guarantees cross language type safety for function calls. It also eliminates the need to write foreign imports directly which saves a lot of code. hsc2hs provides no help for writing function imports. The main disadvantage of c2hs compared to hsc2hs is that c2hs's support for marshaling structures is less than stellar while hsc2hs is pretty good at that. In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. Both are supported by Cabal. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
