|Preprocessor suggestions email@example.com (2001-09-16)|
|Re: Preprocessor suggestions firstname.lastname@example.org (2001-09-20)|
|Re: Preprocessor suggestions Olivier.Ridoux@irisa.fr (Olivier Ridoux) (2001-09-20)|
|From:||Olivier Ridoux <Olivier.Ridoux@irisa.fr>|
|Date:||20 Sep 2001 00:26:29 -0400|
|Organization:||IRISA, Campus de Beaulieu, 35042 Rennes Cedex, FRANCE|
|Posted-Date:||20 Sep 2001 00:26:29 EDT|
> I'd like to start a translator program from C to a much less
> expressive language. My first step would be to modify the c
> preprocessor so that it doesnt swallow up the comments.
> [Leaving comments in the preprocessed code is easy enough, but keeping
> comments in a parser is surprisingly tricky. My usual advice is to
> have a comment field on each token structure and hang comment text on
> the preceding or following token. -John]
Keepin tracks of comments and identifiers is important for the
traceability of source-to-source transformations. My prefered way is
to treat comments as tokens, and attach them to nodes of the syntax
Attaching comments to nodes of the syntax tree raises the question of
where to attach them. To the left, to the right, in the middle (when
a node as two sons), etc?
I have found convenient to attach comments to the lowest n-ary node
(n>1) which contains the phrase at the left of the comment, and the
phrase at the right. If the node is 3-ary or more, the comment will
be attached precisely between the two sons that flank the comment.
Comments that lay at the beginning or at the end of the whole sentence
are only flanked on one side; they are attached to a dummy root-node.
It is up to the processor that uses the syntax tree to do something
smart with the comments. E.g., in a list of C functions, the comments
will be attached to the list CONSes, but the processor will know that
each comment has to do with the CADR of the CONS it is attached to.
Note however that any attempt to attach comments to the syntax has the
effect of formalizing comments though no formalization exists a
priori. Probably, programming languages should be less liberal than C
(and many others), and treat comments as formal objects. This could
lead to a variety of comment types: function comments, declaration
comments, expression comments, section comments, etc.
Return to the
Search the comp.compilers archives again.