Language.C

[Benedikt Huber]

On 11.05.2011, at 04:27, Warren Harris wrote:

> Hi Benedikt,
>
> I'm trying to scope out a project that might use Language.C, and  
> have a question that I hope you might be able to answer. I was  
> wondering if you've ever given any consideration to adding a  
> TemplateHaskell extension that would allow users to use QuasiQuoting  
> within C code. For example:
>
> let ccode = [c|
>     int foo(int x) {
>       $(...more haskell code here...)
>       return x;
>     }
>     |]
> in ...
>
> I think this could be a flexible and powerful way to generate C  
> code, e.g. while walking some other data structure. Using TH seems  
> preferable to calling the Language.C constructors directly.
Hi Warren,
yes, that's really useful!
>
> I spent a little while today trying to write this TemplateHaskell  
> extension and found that it was more challenging that I first  
> thought because TH's QuasiQuoting facility wants to return a Q Exp  
> (quoted haskell expression), and to do this I found I needed a way  
> to print out the Language.C.Syntax.AST tree, and then parse the  
> result using Language.Haskell.Meta.Parse. The problem is that the  
> AST data types don't implement a haskell-compatible printer (e.g.  
> derive Show). Maybe there's some other way to do this?
The current development version of language-c now has a Haskell- 
compatible Show instance (thanks to Alexander Bernauer). The  
application examples/DumpAst.hs does exactly what you are asking for -  
it "show"s an AST and then parses it using haskell-src. Maybe you want  
to try it out?

> The project idea I have in mind is rather like a yacc parser, or  
> forward-chaining production system -- a language for matching  
> complex patterns (as json structures), and when a match is  
> successful, allowing reductions to be specified as C code using  
> variables from the matched patterns. The entire thing would be  
> translated into C, with the reduction code blocks embedded in the  
> resulting C code appropriately. (The reason for translating the  
> entire thing into C is due to other dependencies in the operational  
> environment.)

> It would be great to get your thoughts on the viability of this sort  
> of tool/approach,
Do I understand correctly, the language is meant to be a Haskell EDSL  
with quasi-quoted C fragments?. Concerning quasi-quoting, I think it  
would be _really_ nice to have quasi-quoting support for language-c.  
It is not entirely trivial though, and requires extending the lexer  
and the parser, and some thoughts on how to deal with typedefs (a  
standard set of names known to be typedefs, maybe?).

cheers, benedikt

>
> Warren