Related articles |
---|
Tools to "prettify" source code michael.stumpfl@jkh.uni-linz.ac.at (Michael Stumpfl) (2001-03-28) |
Re: Tools to "prettify" source code idbaxter@semdesigns.com (Ira D. Baxter) (2001-03-31) |
Re: Tools to "prettify" source code viola@pp.htv.fi (Pekka Enberg) (2001-03-31) |
Re: Tools to "prettify" source code eliotm@pacbell.net (Eliot Miranda) (2001-04-04) |
Re: Tools to "prettify" source code perkens@sdm.de (Burkhard Perkens-Golomb) (2001-04-04) |
Re: Tools to "prettify" source code ericbr@oz.net (Eric Brown) (2001-04-04) |
Re: Tools to "prettify" source code marcov@toad.stack.nl (2001-04-10) |
Re: Tools to "prettify" source code idbaxter@semdesigns.com (Ira D. Baxter) (2001-04-10) |
Re: Tools to "prettify" source code broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-04-10) |
Re: Tools to "prettify" source code michael.stumpfl@jkh.uni-linz.ac.at (Michael Stumpfl) (2001-04-10) |
From: | "Ira D. Baxter" <idbaxter@semdesigns.com> |
Newsgroups: | comp.compilers |
Date: | 10 Apr 2001 01:19:14 -0400 |
Organization: | Posted via Supernews, http://www.supernews.com |
References: | 01-03-155 01-03-158 01-04-006 |
Keywords: | tools |
Posted-Date: | 10 Apr 2001 01:19:14 EDT |
"Eliot Miranda" <eliotm@pacbell.net> wrote in message
> "Ira D. Baxter" wrote:
> >
> > Our DMS Reengineering Toolkit parses arbitrary langauges ("domains"),
> > builds ASTs (capturing all the lexical source information such as
> > comments, number formats, etc.), can apply source-to-source
> > transformations to the trees, and finally prettyprint the result.
> > This is driven by a "domain definition" including a grammar and
> > prettyprinting rules.
>
> What approach(es) do you take towards comments? Many comment forms seem
> to cause problems with pretty printing. For example
>
> if (expr) { /* first line of */
> doSomething(); /* of a multi-line comment */
> } /* split across multiple lines */
>
> is this one comment or three? Which parse nodes is/are the comment/s
> attached to?
>
> Many Smalltalks have a pretty printer but I've yet to see one that
> handled comments well.
There isn't a lot you can do with a single conceptual comment that is
physically split across multiple source lines. How can the tool
possibly guess what comment parts the programmer wants to group
together? However, I think this is a failing of the programmer. He
really should have used one comment for this.
We do collect contiguous sequences of comments together, and our
parsers understand the difference between comments coming before a
syntactic structure, and comments that follow them (in your example,
"/* first line of */" gets attached as a precomment to "doSomething",
and "/* of a multi line */" gets attached to "do something" because it
starts on the same line. However, the grouping is still purely
heuristic, because tools can't guess programmer intent.
Your example would be prettyprinted by DMS as:
if (expr)
{ /* first line of */
doSomething(); /* of a multi-line comment */
} /* split across multiple lines */
--
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
http://www.semdesigns.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.