FWIW, I've done a fair bit of work in developing some techniques for
extracting inter-object interfaces from unannotated regular Smalltalk source
code, which I will refrain from calling a "type-inference" system, since
that sort of system was not what I was after.  A better description would be
to call it a means for extracting role-based interfaces from raw source
code.   How well that would correspond to a type-inferencer I'll leave up to
others, but basically that was not my interest.

As has been mentioned elsewhere in this discussion, I don't attempt to start
from absolute, mathematically or otherwise correct first principles in order
to do this, but instead focus on simple heuristics which are often good, but
never guaranteed to be correct.  There are a number of steps in the process,
but it is possible to obtain really encouraging ( though obviously not
entirely correct ) results with very little effort.  This is easily done by
simply walking parse trees, gathering up all the messages sent to things
which are readily identified as expressions.  The result is a set of what
might be considered "candidate" interfaces- although they will tend to be
both incomplete as well as having "extra" messages on them ( obvious to the
casual observer, but not to the computer ), they are nonetheless often
amazingly encouraging.

Coming up with ways to clean up those initial results ( ie, consolidation of
the fragmentary interfaces to make bigger, more complete ones, as well as
trimming them so that the "extraneous" messages are removed ) takes a bit
more effort, though if you come up with the right tricks then that effort
does not actually seem so great either ( coming up with any tricks that
would come even close to working took me quite a long time, but perhaps
others would have stumbled right onto them immediately ).

My main philosophy in this was to simply discover not what the programmer
had thought they had done, but rather what they had actually done.  As
mentioned elsewhere, this decouples having "type" correct code as a
desireable end-goal, from the early stages of a system where one is probably
still groping about for the proper way to build the thing in the first
place.  Later on, when you really really understand what the system ought to
be, then you have the tools to extract information about what objects are
talking to each other, and what they are saying to each other in those
converstations.  That information will sometimes be rather surprising.
Ideally, it also provides for another highly useful means of viewing and
coming to understand large class libraries ( which was my original desire
with this work ).

I don't have performance figures handy to throw about, but if memory serves
it was possible to analyze the source code from complete images ( ie, the
entire class library from VW 3.0, approximately 2000 classes and I think
16,000 methods ) in about 20 minutes on a 300 Mhz celeron with 256 Mb of RAM
( ie, my now-dead laptop ).

Time has been very hard to come by in the past year, and now all of my own
computers are dead so it is getting a bit hard to make much progress.  I
don't want to promise anything, especially since I don't know when I will
have the opportunity to build another computer and have the time to do
anything with this again, but for those that are interested in this sort of
thing I figured I may as well mention it.

Take care- I hope to have more time to poke around with Strongtalk in the
near future.

- les



----- Original Message -----
From: "David Griswold" <David.Griswold at acm.org>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, August 05, 2002 5:39 PM
Subject: Re: Animorphic ST (Strongtalk) released!

[snip!]

> As I think Gilad has also said, there is no reason why what you are
> suggesting couldn't be done just fine with Strongtalk.  Our point is
> that the inferencing you are talking about should be a tool in the
> programming environment, not a part of the type system itself.  We
> wanted to do this too, but just never had time to do it. Note that you
> can already select subexpressions in Strongtalk and ask for their type;
> it would not be that hard to write some simple inference tools that
> would use the typechecker infrastructure to propagate subexpression
> types where possible to try to figure out local variable types or return
> types.
>
> -Dave
>
>
>