Animorphic ST (Strongtalk) released!

Gilad Bracha gilad at bracha.org
Sat Jul 20 15:35:36 UTC 2002


At 07:12 AM 7/20/2002, Andreas Raab wrote:
> > I only looked into Animorphic ST for a couple of minutes so
> > far, but by first impression was, this is how Smalltalk should
> > look like.  Besides the system system, I like the Self-like
> > browers.
>
>I found the type-system the most unnatural part about StrongTalk. It
>feels displaced and if you look at methods like "->" in Object you can
>see that there are some rather nasty complexities associated with it
>(not to mention readability issues).

Indeed, no one claimed that designing a type system for  Smalltalk is easy 
and free of nasty complexities. Your example uses rather elaborate 
constructs that are used fairly infrequently. In fact, I think we could do 
much better on some of those now - as I mentioned in my note to Dan 
Ingalls, there has been progress in type systems, and we may be able to 
give a cleaner type signature in this case.

As far as readability goes - it is still much better than not having a type 
signature at all.


> > In Smalltalk (without types) no tool can exactly know the type of an
> > expression and code completion (with is IMHO the best
> > productivity tool of a modern IDE) cannot offer a valid
> > selection of applicable method names.
>
>That has been said many times and yet, I disagree.

We probably don't disagree as much as you think.
There has been research on type inference for object oriented languages 
like Smalltalk. Inferring all the types is a very hard problem. Partial 
inference, on the other hand, may be quite straightforward. In other words:

1. In some cases, you must use type annotations. Whether that is 10% or not 
is speculation at this point.
2. If you do have some annotations already, it is much easier to infer the 
missing ones.

It is therefore advisable to separate the problems of type checking and 
type reconstruction (as type inference is more properly known).

For example, we always wanted to add an "infer types" option to the 
browser, which would attempt to add missing type annotations; we never got 
around to it, but it certainly would be a nice thing to have.

A programmer would then be able to write regular Smalltalk code and ask the 
system to fill in types as best it can. The annotations would appear in the 
code, and the programmer could then correct them or add information where 
the type reconstruction failed. Then the code could be submitted for 
typechecking.

The advantage of this approach is that you don't restrict your type system 
because of limits of your type reconstruction algorithms. For example:

1) You can use different type reconstruction algorithms at different times 
or in different circumstances. So, if in 2 years you find a cleverer 
approach to type reconstruction, you don't need a new type system.

2) You can use unsound type reconstruction algorithms. In other words, you 
can use heuristics such as guessing the type based on the variable name. 
These may work very well in existing Smalltalk code, but unlike true type
inference, they may produce type annotations that fail typechecking. So you 
cannot rely on them if you don't have a separate typechecker.

The advantages of the separation of type reconstruction ad type checking 
are in some respects analogous to the advantages of separating type 
checking from execution semantics (aka optional typing). You avoid 
constraining one aspect of the language due to limitations of another aspect.

>To the best of my
>knowledge nobody has ever tried to build a simple type inference system
>which just goes along with you as you are writing code and tries to
>discover what the types might be. Name completion and other utilities
>can even be used to tell such a type inference system about what types
>of certain objects are and I still think that you should be able to
>trivially figure out the types for 90% of the system without explicit
>type annotations. For the remaining 10% you _might_ want to use type
>annotations

No, you *certainly* want to do that for the remaining X%. The best type 
reconstruction system around for object oriented languages is probably in 
OCaml.  It isn't clear to me that something like that would apply to 
Smalltalk at all. In any case, it is still recommended to explicitly 
annotate APIs at module boundaries in OCaml to prevent representation 
information leaking out through the inferred types.

>but I would hope that some better syntax can be found than
>is currently in both StrongTalk and SmallScript.

I don't argue with people over surface syntax. It is a highly emotional and 
subjective issue for people, even though it is fundamentally trivial. I 
will note that we had to retrofit a syntax that parsed, onto the existing 
Smalltalk syntax. This constrains things a good deal. Feel free to suggest 
concrete improvements.


> > Currently, I'm working with a very large (VisualAge Smalltalk project
> > which was grown over the last five years or so - and most original
> > developers left the company long ago - and it's awful
> > difficult, I want Eclipse (and Java) back.   Never thought, that
> > I'd say that but if mediocre programmers hack quick fixes into
> > a system for a couple of years, Smalltalk becomes a mess.
> > This is probably true for other languages, too, but at least
> > types would give you some kind of documentation.
>
>But of course you do realize that *optional* types would hardly ever be
>used by mediocre programmers do you?! So that an implicit type system
>would (arguably) be more useful than an explicit one that isn't used.

As noted above, a completely implicit system isn't an option. However, you 
do have a point that people might not use it when they most need it. We 
discussed this precise issue back in the Animorphic days, with commercial 
Smalltalk development in mind. Our view was that this was a management 
issue. One could easily set a switch to require type checking - either all 
the time, or just before code went into production or integration etc.


Cheers,  Gilad

*********************************************
Gilad Bracha
Computational Theologist
Sun Java Software
http://java.sun.com/people/gbracha/




More information about the Squeak-dev mailing list