|Generating Source Code. firstname.lastname@example.org (1999-10-06)|
|Re: Generating Source Code. email@example.com (Rodney M. Bates) (1999-10-11)|
|Re: Generating Source Code. firstname.lastname@example.org (David Chase) (1999-10-11)|
|Re: Generating Source Code. email@example.com (Craig Smith) (1999-10-11)|
|Re: Generating Source Code. firstname.lastname@example.org (Christopher W. Milner) (1999-10-11)|
|Re: Generating Source Code. email@example.com (1999-10-13)|
|Re: Generating Source Code. firstname.lastname@example.org (Scott Stanchfield) (1999-10-13)|
|Re: Generating Source Code. email@example.com (H. Ellenberger) (1999-10-14)|
|Re: Generating Source Code. firstname.lastname@example.org (Vadim Maslov) (1999-10-16)|
|Re: Generating Source Code. email@example.com (Christian Stapfer) (1999-10-21)|
|From:||"Scott Stanchfield" <firstname.lastname@example.org>|
|Date:||13 Oct 1999 01:17:35 -0400|
|Organization:||Posted via Supernews, http://www.supernews.com|
Rodney M. Bates <email@example.com> wrote in message
> For each syntactic construct, the formatting routine tries to display
> it "horizontally", i.e. all on one line, given a starting position on
> the current line. If it won't fit, then it is displayed "vertically",
> i.e. on multiple lines. Each construct has its own rule for vertical
> formatting. Either way, the nested constructs are formatted in their
> own way.
> The kicker is that the starting position has to come from the parent
> construct, and the parent formatting routine doesn't know this yet,
> until it has seen how much space the children constructs will require.
Seems to me that a nice way to deal with nesting would be to use the
LayoutManager approach taken in Java's AWT libraries (a strategy
If we were to come up with a "layout manager" for each type of
construct, it could perform layout on its children, asking them for
their "preferred size". The children have layouts as well, which
return preferred size based on _their_ children and so on.
This type of strategy leads to very simple layout manager design
(ain't recusrion grand!) _and_ ease of changing layout strategies. You
can simply plug in different layout strategies for the AST nodes to
change layout behavior for different user styles.
This type of thing has been done in the Swing text framework.
Take a look at the Swing text framework (see
http://www.theswingconnection.com for some details). They use an
Element/View representation to display the data. Elements map nicely to
ASTs (well, they really _are_ an AST of the text's layout). Views are
like layout managers, showing how to display the data on the screen.
There's built-in help for tweaking display (splitting and combining
lines as necessary).
The Swing text framework is rather complex, but designed for just this
type of work to display a document.
You could use this as a model for the pretty printer, or perhaps create
a set of Views that write code to a file.
Hope this spawns some interesting discussion...
Scott Stanchfield firstname.lastname@example.org http://www.jGuru.com/thetick
jGuru Training by MageLang Institute http://www.jGuru.com
VisualAge for Java Tips --> http://www.jGuru.com/thetick/visualage/tips
Return to the
Search the comp.compilers archives again.