language.c: support for statements in MonadTrav

Benedikt Huber benedikt.huber at
Wed Feb 2 13:41:08 GMT 2011

On 01.02.2011, at 09:31, Alexander Bernauer wrote:
> Hi
> On Mon, Jan 31, 2011 at 10:56:19PM +0100, Benedikt Huber wrote:
>> MonadTrav was and is, AFAIK, mostly used to collect
>> declarations and build an intermediate representation of the program.
> So, MonadTrav and especially AstAnalysis peform a convertion from
> Syntax.AST to Analysis.SemRep, right?
Yes, to be more precise:
* MonadTrav provides symbol table, unique name generation and error  
handling facilities, to simplify the semantic analysis of the AST.  
Additionally it provides callbacks (but currently not for statements,  
as you noticed).

* analyseAST traverses the translation unit and collects all  
declarations, definitions and types; additionally it typechecks the  
source (see analyzeFunctionBody in AstAnalysis).

* The SemRep datatypes provide a greatly simplified view on  
declarations and types (they are really complicated and difficult to  
handle in the original AST).

> Is there also a way to go back?

The SemRep data /should/ be linked with the original AST via NodeInfo  
names, but I think this has not been used so far; and I do not know if  
the connection is always accurate.

> Or can you pretty print the SemRep objects?

Generating code from the SemRep presentation is possible of course,  
but there is only an implementation sketch so far (Analysis.Export).

> In either case (if existant), if I go C-code --parser--> Syntax.AST

> --astAnalysis--> Analysis.SemRep --"inverting"--> C-code, how much  
> does the output differ from the input?

Probably a lot. Do you care? If you want to keep the transformed  
program as close as possible to the original one, you have to work on  
the original AST. It should be possible to reuse all the helper  
functions from the analysis modules though, so you do not have to re- 
implement type analysis/type checking, for example.

>> 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?).
> I am not sure if I get this. What I would like to have is a visitor  
> for
> ASTs. For example I want to determine the call graph of a program.  
> So I
> have to traverse all function definitions looking for function calls.
Ah, sorry. What I had in mind is that visitors are not necessary if  
you can use generic programming [ 

But on the raw C AST, generic programming is not trivial, because you  
need to have symbol tables and type information at hand to do  
something useful. For example, when building a callgraph, you need to  
know the current state of the symbol table at each call site, because  
a local definition might shadow a global one.

> For this and many other similar tasks having a generic  
> implementation of
> the visitor pattern on ASTs would help. CIL provides this by means of
> the cilVisitor class [1].
> Maybe this differs from the scope of MonadTrav. In that case I would  
> go
> on and try to implement a visitor framework.
I think this should be possible using MonadTrav; but I haven't tried  
it myself.
>> One important aspect is taking care of declarations (which are quite
>> difficult 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 statements and expressions (that's what CIL does,
>> right?).
> CIL has only one family of types that represent C programs. Whether it
> is closer to Syntax.AST or to Analysis.SemRep I can't say currently.
CIL does a lot of preprocessing, which greatly simplifies the C AST.  
If this is an option for you, maybe [1] would be interesting to you.

Otherwise, you will benefit from Language.C exposing all the  
cruelities of the C Syntax :)



> best
> Alex
> [1]
> _______________________________________________
> Language-c mailing list
> Language-c at

More information about the Language-c mailing list