Can someone read Smalltalk?

[helius]

Smalltalk is a dynamic language and so static analysis has limited usefulness. The most dramatic example of this is the become: message, which makes any two objects change places: all references to one now point to the other and vice-versa. This kind of operation is a problem for attempting to prove what is going to happen, although it isn't the only problem; methods can also be added and removed at runtime.

[tggzzz]

Smalltalk is a dynamic language and so static analysis has limited usefulness. The most dramatic example of this is the become: message, which makes any two objects change places: all references to one now point to the other and vice-versa. This kind of operation is a problem for attempting to prove what is going to happen, although it isn't the only problem; methods can also be added and removed at runtime.

That's all true and relevant, but the limitations of static analysis are much wider than that.

Essentially static analysis of unconstrained programs (e.g. any of the C family) is equivalent to the Halting Problem. And we all know tractable that isn't!

Static analysis can help solve a limited subset of problems in well-defined constrained circumstances.

[helius]

It seems to work fairly well in languages with inferred, parametric types (the ML family)

[tggzzz]

It seems to work fairly well in languages with inferred, parametric types (the ML family)

Not having used *ML nor Haskell, I don't have a valid opinion.  My understanding is that they are specifically designed to enable optimization based on type inferences. I don't understand the constraints nor the consequences. Nonetheless, I presuming they support "objects" in a vaguely Smalltalk sense, I don't see how  they can avoid needing a good GC.

[helius]

If you have a closed-world assumption (which is not possible in a dynamic language without a lot of careful work, c.f. Dylan's "sealing" operation), you can view the execution environment as a kind of DAG that changes at each program step. Whenever a subgraph gets isolated, it is garbage, and you can reclaim its storage at that point. This was called "compile-time garbage collection" in the Concurrent Clean literature. Basically you need to know the input and output types and the side effects of all the functions in the graph. This is also very similar to Henry Baker's "linear lisp" concept as described in his papers.
In practice, I don't know if this static approach is really an advantage. With a copying GC, you tend to have better cache locality, although the precise point in the computation when tracing happens is less predictable and can have a major impact.