Re: Incorporating comments in syntax tree?

ok@cs.rmit.edu.au (Richard A. O'Keefe)
1 Feb 1996 21:40:08 -0500

          From comp.compilers

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]
| List of all articles for this month |
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.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.