Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?

newer
Reducing code for efficient ShowS

older
Is it usual to read a Maybe (IORef...

Justin Bailey

4 Sep 2008 4 Sep '08

10 p.m.

On Thu, Sep 4, 2008 at 2:52 PM, Philippa Cowderoy 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

Show replies by date

Brandon S. Allbery KF8NH

4 Sep 4 Sep

10:03 p.m.

New subject: 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 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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Austin Seipp

5 Sep 5 Sep

1:04 a.m.

New subject: 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

David Roundy

3:14 p.m.

New subject: 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

6149

Age (days ago)

6150

Last active (days ago)

List overview

Download

3 comments

4 participants

participants (4)

Austin Seipp
Brandon S. Allbery KF8NH
David Roundy
Justin Bailey