The crushing blow to using a Java-style type checker in Smalltalk is
that you'd have to give up programming in the debugger.  Maybe it is
theoretically possible to achieve it, but witness that despite enormous
efforts being put into Java development tools, the best ones still have
very limited abilities to modify a class while it has instances still
executing.  If you change the type of an instance variable, or remove a
variable that is still used in some methods, it's just too hard and the
existing tools all stop the execution (or some large chunk of the
execution).  It's the type system that makes it so hard; languages
without static type systems have no trouble with solutions like "just
stick nil in there" or "let every variable hold any kind of object".

That said, Squeak is not entirely without static checks, and it could
even use a few more.  For example, if you type in "Array new
initialiize" and try to execute, Squeak will ask if you really menat to
type "initialiize".  If you type in "asdf := asdf + 1", it will complain
that "asdf" is not a variable that exists.  These are useful static
checks that do *not* interfere with the lovely programming in the
debugger we are used to.  There is room for even more such checking. 
For example, consider cases like "self foo" where you know something
more than normal about the message receiver.

Even though a Java-like type checker doesn't make sense in Squeak, there
is a lot of work in static (and dynamic!!) types that makes sense to
explore.  For type checking itself, you can explore what Andreas
describes: a system where checking errors result in warnings popping up,
not in rejection of the program.  The type system itself could even look
like one from some other OO language, but a lot of thought needs to be
put into how the type system is used and what happens when type errors
happen.  I haven't bumped into any system at all which has a
sophisticated way to handle type errors; almost every checker around
simply rejects the program entirely if there is even one type error in
it.

Additionally, why focus so much on checking?  Types are useful for other
purposes than checking, purposes which IMHO are much more valuable than
the small amount of checking that I believe type checking gives you. 
For example, you can try to use types for documentation, design help of
the kind Blake described, and improving navigation through the browsers.
 If you start with one of these alternate goals, you may end up with
something very different from a classic type checker.

At any rate, if you want to do something with types, then focus on
particular problems and particular solutions.  Reliable message-binding
is not a problem in practice; if you scan Squeak's bug logs, you see
many more errors for uninitialized variables (ie message sent to nil)
than for true type errors (other MessageNotUnderstood's).  Further,
reliable message-binding does not appear to be solvable in an OO
language; you just don't know for sure until you run the program.  As I
posted earlier, the best a type system can do is trivially transform the
error into some other kind of error.  Let's not waste energy solving an
unsolvable problem that has little benefit.

I'm not saying to dump it all.  Go ahead and explore types, but don't
expect to directly copy much from other languages.  The fact that
Smalltalk supports programming in the debugger, makes it enough
different from other languages that type checkers for those languages
just don't transfer.


-Lex