Language.C

[Warren Harris]

On Wed, May 11, 2011 at 4:06 PM, Benedikt Huber <benedikt.huber at gmail.com>wrote:

>
> 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?


That sounds like what I was looking for. I noticed that 'show' will either
print things as C syntax (e.g. a CInteger will print out as "123" rather
than "CInteger 123"), or using a syntax for readability (e.g. identifiers
print as `foo' rather than as "Ident \"foo\" ..."). But maybe DumpAst.hs
will do the right thing.


>
>
>  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?).
>
>
I'm not sure I follow why the lexer and parser would need to be extended,
but I haven't looked at it that closely yet. I was hoping that with the
trick of calling effectively: "Language.Haskell.Meta.Parse.parseExp . dump .
parseC" that might be all that was needed, but maybe not. If I get time,
I'll try to dig into this a bit more in the next few days.

Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/language-c/attachments/20110511/dcc876ec/attachment.htm>