language.c: support for statements in MonadTrav
benedikt.huber at gmail.com
Mon Jan 31 21:56:19 GMT 2011
On 30.01.2011, at 17:26, Alexander Bernauer wrote:
> Hi Benedikt,
> Before I got to know language.c I had been using CIL  which is
> roughly the OCaml equivalent of language.c. CIL offers a visitor class
> which can be used to traverse ASTs. To this end the user can provide
> hook functions for various C constructs such as declarations,
> expressions and statements.
> I spent the whole weekend reading the language.c source code (and
> learning Haskell along the way). So I think it's correct to state the
> The language.c way of traversing ASTs is the MonadTrav class. But it
> only supports declarations and there are only stubs for the SemRep
> of expressions and statements up to now. From that I assume that you
> have been planning to extend the MonadTrav already.
Background info on the status of language-c:
while the parser/pretty printer stuff is more or
less completed (already as of 0.3), the analysis is still work-in-
Moreover, a lot of work in the analysis module was done by Aaron (CCed),
who implemented the type checking facilities, and maybe knows a better
answer to your question than I do. Originally, the analysis facilities
language-c where tailored towards the needs of c2hs (where Language.C
originated from). MonadTrav was and is, AFAIK, mostly used to collect
declarations and build an intermediate representation of the program.
> I need statement and expression support for AST traversal so badly
> I will go on and implement it. That's for sure. The question is,
> if I will (and manage to) integrate it into the existing language.c
> infrastructure or if I will just code it up myself.
> I would love to go the former way. But for that I am afraid I will
> you to support me because I am not sure if I could understand how you
> inteded to do it.
> My guess is that MonadTrav needs additional hook functions for
> and expressions. Furthermore, we need functions which starting from an
> AST node visit all children in order and trigger the corresponding
> functions. Concerning the inteded SemRep types for statements and
> expressions, though, I have no clue.
Hmm, I'm not sure which strategy is best. I hope Aaron has a helpful
on this one.
The tricky part is to provide a somewhat simplified view on the C AST,
library client does not have to deal with all the difficult aspects of
the C language
itself (otherwise, where is the benefit in having traversal callbacks?).
One important aspect is taking care of declarations (which are quite
to handle in C), and provide the info from type checking. I'm not sure
what else you
would need; especially whether you really need a full IR for
expressions (that's what CIL does, right?).
>  http://www.cs.berkeley.edu/~necula/cil/
More information about the Language-c