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
|