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

[David Roundy]

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