Here are two short repliees condensed into one, to try and save a bit of
mailing list traffic.


Peter van Rooijen <peter at vanrooijen.com> wrote:
> Of course I'm curious how Chuck got its name :-).
> 

Mostly, it is just a humble name a la Smalltalk itself.  Also, though,
it works by "chucking" ideas at a wall and seeing what sticks.


> I have just a suggestion : could this AutoChuck feature be turned
> on only on certain packages, such as Kernel and not Morphic for example 
> ?
> This could spare some time and quit a bit of space ...
> 

I'm working on the space requirements, but wanted to go ahead and post
the system as is for the diehards.  Memory usage is not the only area
that is lacking I'm afraid!

The major memory requirement, it turns out, is that AutoChuck is keeping
around parse trees for every method.  So I'm trying to eithre get rid of
that requirement or make the parse trees take less memory.

The particular idea of caching part of the system seems difficult to
implement.  If you ask what the type of Morph>>width is, it will end up
tracing into methods in Rectangle, which will in turn trace into methods
in the numeric hierarchy.  So what parts do you *really* need if you
just want to analyze morphic stuff?  It's hard to tell.


Romain Robbes <rrobbes at info.unicaen.fr> wrote:
> A while ago I started (I mean, played 3 hours ;-)) a little program to 
> store type
> information which could then be used by several tools, such as a type 
> inferencer,
> an the toy I was doing, which was collecting run-time types, so they
> could "collaborate". This could then be used by a code completion 
> system,
> or various navigation systems (how about clicking on a variable and 
> being
> automagically teleported to it's class ?).

Oh yes, this is a great tool too, and it complements what Chuck does.

Chuck examines the program and gives you an upper bound on what the
types might ever be; your tool examines executions and thus finds a
*lower* bound on the types.  Your tool is, I'm sure, consistently fast;
on the other hand, Chuck will find a good many answers even in code that
has yet to be executed.  This is nice if you have not yet figured out
how to run the code you are studying!  

Also, upper bounds on the types have different applications in
downstream tools such as compilers and dead code removers; a lower bound
can inform the compiler that a case is worth optimizing (e.g. this
method really does get run with FloatArray's), and an upper bound can
let the compiler *avoid* dealing with certain cases (e.g., this message
send can only ever invoke one particular method, so inline it).


Lex