language.c: support for statements in MonadTrav
benedikt.huber at gmail.com
Wed Feb 2 13:41:08 GMT 2011
On 01.02.2011, at 09:31, Alexander Bernauer wrote:
> 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
>> 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
> 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 [http://d.hatena.ne.jp/syd_syd/20080813#p1
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 .
> Maybe this differs from the scope of MonadTrav. In that case I would
> on and try to implement a visitor framework.
I think this should be possible using MonadTrav; but I haven't tried
>> 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,
> 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  would be interesting to you.
Otherwise, you will benefit from Language.C exposing all the
cruelities of the C Syntax :)
>  http://www.cs.berkeley.edu/~necula/cil/api/Cil.cilVisitor.html
> Language-c mailing list
> Language-c at projects.haskell.org
More information about the Language-c