Re: Approaches to code formatters

Piotr Zgorecki <pioter@terramail.cutthis.pl> wrote:
> I decided not to have any parser, [...]


A parser is not necessary, nor is a full scanner. It is sufficient to
recognize classes of tokens, like operators and literals, as well as
a few classes of keywords which are used to control the formatting of
the code.


White space and indentation can be handled by assigning properties to
classes of tokens. For example, the left brace in c may be assigned
the properties


pad (emit a space before this token (except at the beginning of a line))
rbrk (emit a newline after this token)
sid (start indentation)


and the right brace may be assigned


lbrk (emit a newline before this token)
rbrk (as above)
eid (end indentation)


Using these properties, the statement


if(x>y){x=y}


would be formatted this way:


if(x>y) {
x=y
}


Similar properties can be assigned to other classes of tokens. Of
course, there are many tokens which influence each other. For example,
a space character should be emitted between 'if' and '(', but no space
should be emitted between 'f' and '(' in 'f()'.


The T3X pretty printer (tools/txprint.t in the T3X source code
distribution at www.t3x.org/T3X/compilers.html) implements a complete
set of properties for formatting T3X code. Re-writing the formatter
to handle C should not be too hard.


An additional degree of flexibility could be added by reading
properties from a rule file rather than including them in the
source code.


Good luck,


Nils.
--
Nils M Holm <nmh@t3x.org> -- http://www.not-compatible.org/nmh/

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