[Haskell-cafe] Consequences of implementing a library in
Haskell for C consumption?
droundy at darcs.net
Fri Sep 5 11:14:44 EDT 2008
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:
> 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.
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.
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
class CConst i where
mkConst i :: ???
instance CConst Int
instance CConst Double
More information about the Haskell-Cafe