Hi dan

what you describe is a kind of dream. Just before the BC compiler 
arrived, I started to write another pretty printer
but based on the Squeak AST.  Then I stopped because I thought that the 
AST would change. I was never happy with the result.
But in the process I learned that
	- the AST design can also help a lot (lex confirmed that in lucid) 
having for example a parent link as in RB AST makes a lot of stuff 
easier,
	- having a Visitor is a good to achieve variation for the pretty 
printers (note the s). because this visitor could be used to
	fileout code also or generate new syntax or HTML.
	- I was really not happy at all with my result because it was not 
clever enough to be tweaked. Also writing the tests
for the pretty printer was difficult because testing the AST was not 
good, but testing the resulting pretty printed code
was tedious because everytimes I took into account a new construct I 
may break a lot of tests. Still I wanted to be sure
that all the case were well printed.

For the type inferencer, Gilad Bracha was visiting us recently and he 
made a really improtant point about the
idea that you want to have pluggable type system: type system that do 
not interfere with the language semantics.
I will ask him if I can put the slides on the web. One nice consequence 
is that in fact you would like to be able to annotate
any AST elements and also instance variables.
So this could be a task for the Compiler Cleaning effort: using the RB 
AST will already be a step in that direction (this
was sad to see that Lex, Anthony and me did the same effort in parallel 
because we needed

For the type or role, I think that this is extremely  important for the 
instance variables.
So normally I used roles for instance variables and type for arguments. 
But I agree I would really value a type inferencer.
May be this is the time to make call for tools :)

Stef

On 28 févr. 04, at 19:32, Dan Ingalls wrote:

>> I agree with this. Removing formatting from code is really a "lossy
>> compression" and it looses lots of valuable information. And it's not 
>> just
>> that poorly formatted code is often a sign of inexperience or bugs - 
>> it's
>> also that (at least for me) the style and consistency of a method 
>> says a lot
>> about who has written it, how many people have been working on it and
>> similar things. In short, the way in which a method is formatted 
>> reveils a
>> lot of subtle information about the writer, its intent and its general
>> working style. I am not certain we want to loose that information.
>
> I agree with Andreas about this, but I think it is more a statement 
> about loss in our current formatter than about the impossibility of 
> good automatic formatting.  I think we could get *quite close* to 
> something that made us all happy with just a bit more energy put into 
> the formatter.
>
> For instance...
>
> 1.  Include more white space as real information.  I *think* this is 
> what bothers Andreas about lossiness of the current formatter.  For 
> instance, skipping a line between significant sections is one of the 
> most useful gestures in good coding.  Also comments embedded in, or to 
> the right of code are different from line-long comments, and ought to 
> be kept as such.
>
> 2.  Make it easy to personalize the formatter with regard to such 
> issues as spaces around binary ops and return arrow, empty line before 
> code, block header spading, etc.  A set of check boxes and a method in 
> view that changes as you check them.
>
> 3.  Put some work into the defaults, with input from the community and 
> suggestions like Kent's.
>
> While I know everyone feels differently about various details, I don't 
> think that a wonderful formatter should be considered an 
> impossibility.  I worked pretty hard on the current one years ago, but 
> stopped short of some of the white space subtleties.
>
> It would be nice to have a "benchmark" piece of code that included 
> both challenging structures and tasteful commenting and code.  Then we 
> could all judge whether we basically approved or disapproved of a 
> given formatter (and it's personalizing options).  Each time someone 
> came up with a new challenge, its archetypal example could be added to 
> the benchmark and the formatter tweaked until we were happy with the 
> result.
>
> 	- Dan
>
> PS:  On the topic of variable names, I happen to oppose the "aString" 
> style of variable naming except when you really can't think of 
> anything better.  I feel a variable should be typed by its type, and 
> named by its role (ie "boxCount" instead of "anInteger".  
> Unfortunately we don't have a type inference system and a button to 
> show the types when we want them.  Me, I'm going to keep naming by 
> role, and encouraging work on type inference.
>