From: Nikolai Weibull <ruby-talk@...>
Date: 2003-10-11T19:53:00+09:00
Subject: Re: Project suggestion: Ruby code indenter

* Aaron Son <aaronson@uiuc.edu> [Oct, 11 2003 03:30]:
>
> You mention yacc/racc, and I was curious as to your opinions on the
> subject of an indent like program and the best way to approach it.
>
> Due to the limitations of editors and the like, real-time indentation
> calculation is inherently error prone because we're working with a
> subset of the file and the more accuracy we want in the heuristics of the
> indentation, the more complex our scripts which are responsible for said
> indentation become.
>
Yes, this is the main problem we face.  With limited context we can also
only get limited usefulness.
>
> One way to approach the problem when writing an external program which
> is responsible for re-indenting a file would be to parse the file into a
> kind of verbose abstract syntax tree and then write the tree back out
> using straight forward rules regarding indentation and white space.
>
Yes, this is precisely the idea I had for it.  I don't know if it's
possible to get right though.
>
> This has straight-forward advantages and disadvantages, as well as
> consequences which I'm probably overlooking.  The major advantage that I
> see is that the resulting file could be almost prefect given that we had
> a parser for the complete grammar.  One of the disadvantages would be
> that things like same-line comments would probably get converted to
> full-line comments or vice-versa more often than desirable.
>
Yes, this may be a problem.  The more information about the file you
store in the 'verbose abstract syntax tree' though, the more you can
keep the old structure as well.
>
> I'm also not sure about the relative performances of the two
> methods...on one hand parsing the entire file into a syntax tree is
> processor intensive and requires memory space for the tree (although
> the file could be parsed incrementally I suppose, writing out the
> nodes that we're currently at as long as they're "closed", meaning
> they would no longer affect the indentation of elements to come),
> whereas parsing regarding a large set of regular expressions requires
> running the buffer of text through multiple regexes, etc.
>
This is probably not a problem.  Source files are generally not very
large.
>
> Personally, I think grammars and parsers are pretty fun/neat, so writing
> an indent-like program using them would probably be more interesting
> than writing one using a sequence of regular expressions similar to
> writing a syntax file.  What's the normal way of doing this (i.e. how
> are indent and astyle implemented) and what do you think would be the
> best?  Any advantages or disadvantages of the methods that I'm not
> seeing?
>
indent(1) works by lexing the C file and basically applying heuristic
rules to it.  astyle I don't know.  The main advantage is that it works
rather well ;-). The main disadvantage is that it is only heuristic.
It's not necessarily correct, (or, as the indent(1) manual states "it is
not guaranteed that running indent on the same file will generate the
same output every time"),
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}