For anyone interested, I finally finished cleaning up and documenting
the type inference system I demoed at OOPSLA.  It is at:

	http://www.cc.gatech.edu/~lex/ti/ti.html


This is a work in progress.  Currently, it only handles what might be
called the "Basic Algorithm", and does not implement splitting context
by, for instance, Ole Agesen's CPA algorithm.  Furthermore the system is
too slow if the analysis "escapes" and starts roaming all over the
system.  Some progress has been made in this area--now it is possible to
at least *parse* the entire system's code in about half an hour, using a
"mere" 33 megabytes of space--but the inferencer itself is still
awefully slow.  (aside: if your process runs for hours, you don't need
MessageTally--just hit alt-. every once in a while :))  Plus it's
missing a lot of grunt work such as putting in a table of primitive
response types (Except for basicNew, all primitives are assumed to
return an arbitrary type).

On a technical note, this system avoids the reliance on a "start
expression".  Thus if you ask for the type of a method parameter, the
inferencer tries all senders of the method's selector to be potential
callers contributing to the parameter's type; it does not limit
consideration to methods which have been seen already for a different
reason, nor does it just give up and assume the parameter might just be
anything.  On the other hand, if you are winnowing then you probably
*do* have a start expression, and thus some of those callers could be
skipped.   Anyway, I'm more interested in the program understanding
angle right now, and so this system reflects my bias.

The "smart senders-of" tool that I demoed is included.  Mostly this is
useful, although occasionally the inferencer gets bogged down and one
has to interrupt it and give up.  Also included is the core of a
"winnower" (?) for image stripping, although the inferencer seems to be
too slow to be used for this right now.

Comments are welcome.

Lex