Related articles |
---|
Incorporating comments in syntax tree? ag129@ucs.cam.ac.uk (1996-01-30) |
Re: Incorporating comments in syntax tree? Steve_Kilbane@cegelecproj.co.uk (1996-01-31) |
Re: Incorporating comments in syntax tree? ok@cs.rmit.edu.au (1996-02-01) |
Re: Incorporating comments in syntax tree? solution@gate.net (1996-02-01) |
Re: Incorporating comments in syntax tree? synaptx!thymus!daveg@uunet.uu.net (Dave Gillespie) (1996-02-02) |
Re: Incorporating comments in syntax tree? nadav@cc.huji.ac.il (Nadav Aharoni) (1996-02-02) |
Re: Incorporating comments in syntax tree? cef@geodesic.com (Charles Fiterman) (1996-02-02) |
Re: Incorporating comments in syntax tree? Uwe.Assmann@inria.fr (1996-02-09) |
Re: Incorporating comments in syntax tree? greg.titus@attws.com (Greg Titus) (1996-02-13) |
[1 later articles] |
From: | ok@cs.rmit.edu.au (Richard A. O'Keefe) |
Newsgroups: | comp.compilers,comp.compilers.tools.pccts |
Date: | 1 Feb 1996 21:40:08 -0500 |
Organization: | Comp Sci, RMIT, Melbourne, Australia |
References: | 96-01-121 |
Keywords: | analysis, syntax |
ag129@ucs.cam.ac.uk (A. Grant) writes:
>Does anyone know of any techniques for reading comments in compiler
>input and associating them with the syntax tree /// ?
My IBM Prolog -> Quintus Prolog translator had to do this, because it
was a requirement that comments be preserved in the translation.
Our moderator wrote
>[The most common technique I know of is to hang them from the preceding or
>following token, or if you're feeling clever, maybe a nearby control
>structure to which they seem to apply. I've never heard of a technique
>that was entirely satisfactory. -John]
and that's more or less what I did, except that block comments before a
procedure clearly ought to bind to the whole procedure, not to the first
token of the procedure. This matters because it is possible to have
/* rave on for 50 lines */
*mine is_bigger_than *yours <-
*mine = prolog & *yours = c.
translating to
is_bigger_than(Mine, Yours) :-
Mine = prolog, Yours = c.
where stuffing 50 line comment inside the "procedure heading" is clearly
a bad idea. Indeed, the same thing happens inside a procedure
/* size counts */ *his is_bigger_than *hers
should translate to
/* size counts */ is_bigger_than(His, Hers)
rather than
is_bigger_than(/* size counts */ His, Hers)
It is particularly tricky when the translation may contain several copies
of the commented item. Here's another example:
p(int $ *age /* in months */, int $ *weight /* in kilos */) <-
*age > *weight.
Should this translate to
p(Age /* in months */, Weight /* in kilos */) :-
integer(Age /* in months */),
integer(Weight /* in kilos */),
Age > Weight.
or to
p(Age /* in months */, Weight /* in kilos */) :-
integer(Age),
integer(Weight),
Age > Weight.
My preference is for the latter, to strip all copies of a tree except the
leftmost of their comments. If I recall correctly, I implemented the former.
The really nasty problem comes when a portion of the input is deleted in the
output. When translating from one dialect to another, this may occur. As it
happens, Quintus Prolog and IBM Prolog both have floating point numbers, but
you could imagine
p(float $ *x) <- q(*x). /* clause 1 */
p(int $ *x) <- r(*x). /* clause 2 */
being translated to
p(X) :- integer(X), r(X). /* clause 2 */
By studying existing well-commented code, I was able to find a set of rules
which worked well *for code commented that way*. For code with a different
attachment style, the rules could produce ludicrous results. Fortunately,
the code the translator was written for was well commented.
--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.