Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
On Thu, Sep 04, 2008 at 08:04:25PM -0500, Austin Seipp wrote: Excerpts from Justin Bailey's message of Thu Sep 04 17:00:58 -0500 2008: Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, The AST Language.C defines for C is actually fairly regular once you wrap your head around it - I got it to generate working programs that I could compile in approximately an hour after looking through nothing but the documentation, essentially. The AST is very 'raw' though: I found that defining some simple functions for things like just creating a global variable, creating declarations and the like cut down on overall AST size tremendously (although hints of the AST types/constructors were still around, naturally.) Here's the example I put on HPaste a few days ago: http://hpaste.org/10059#a1 You'll notice that the actual shim you're looking at - with the help of the defined functions - is actually fairly small, and those functions help out with those *a lot.* That was the first thing I wrote with it though, so the functions could probably be further generalized and abstracted. Nice. On that note (although a little OT,) does anybody think it would be nice to have a higher level library designed specifically around emitting C that uses Language.C? A lot of repetetive stuff can be cut down considerably, I think. That sounds great to me. I'd love to see something like this with some handy classes, so that I could write my haskell code using Int and/or Integer rather than CInt. e.g. change mkConst (ConInt i) = CConst $ CIntConst (cInteger i) undef mkConst (ConChar c) = CConst $ CCharConst (cChar c) undef mkConst (ConFloat f) = CConst $ CFloatConst (readCFloat f) undef mkConst (ConStr s) = CConst $ CStrConst (cString s) undef to class CConst i where mkConst i :: ??? instance CConst Int instance CConst Double etc. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual (Foreign function interface), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The library will not expose any higher-order functions or other business. It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Thanks in advance for any thoughts. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
jgbailey: I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual (Foreign function interface), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The Yes. library will not expose any higher-order functions or other business. You still need the GHC runtime support for the Haskell code (GC, scheduler et al). It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Easy enough to do, http://haskell.org/haskellwiki/Calling_Haskell_from_C Would be great to hear how you find the experience. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy [EMAIL PROTECTED] wrote: Would writing Haskell to generate the C via Language.C be an option? Effectively you'd be using Haskell as a typeful macro system. Interesting idea, and I've done similar things with haskelldb (generating SQL queries). Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, and it doesn't seem to incorporate any type information in the AST items. In haskelldb, every expression carries its type around in a phantom type, which protects you from trying to compare a bool and a string, for intstance. I don't see anything similar in Language.C. I may be mistaken though! Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
On 2008 Sep 4, at 18:00, Justin Bailey wrote: On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy [EMAIL PROTECTED] wrote: Would writing Haskell to generate the C via Language.C be an option? Effectively you'd be using Haskell as a typeful macro system. Interesting idea, and I've done similar things with haskelldb (generating SQL queries). Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, and it doesn't seem to incorporate any type information in the AST items. Compared to Haskell (or HaskellDB), C barely has type information and is very non-strict about what types are compatible with what types. (And I'd wonder how Language.C deals with typedef, which is to C parsing what fixity declarations are to Haskell parsing [which is to say, painful].) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
Excerpts from Justin Bailey's message of Thu Sep 04 17:00:58 -0500 2008: Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, The AST Language.C defines for C is actually fairly regular once you wrap your head around it - I got it to generate working programs that I could compile in approximately an hour after looking through nothing but the documentation, essentially. The AST is very 'raw' though: I found that defining some simple functions for things like just creating a global variable, creating declarations and the like cut down on overall AST size tremendously (although hints of the AST types/constructors were still around, naturally.) Here's the example I put on HPaste a few days ago: http://hpaste.org/10059#a1 You'll notice that the actual shim you're looking at - with the help of the defined functions - is actually fairly small, and those functions help out with those *a lot.* That was the first thing I wrote with it though, so the functions could probably be further generalized and abstracted. On that note (although a little OT,) does anybody think it would be nice to have a higher level library designed specifically around emitting C that uses Language.C? A lot of repetetive stuff can be cut down considerably, I think. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
