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/