Animorphic ST (Strongtalk) released!

David Griswold David.Griswold at acm.org
Mon Aug 5 22:39:45 UTC 2002


Stefan Matthias Aust wrote:

> David Griswold wrote:
> > Hi Stefan and Andreas,
> >
> > Sorry for the late reply- I've been offline for the last few days.
>
> Thanks for your explainations.  Somehow I thought "VarAssoc" means
> association for variables and not an association which can be
> modified
> so I wondered why you need to propagate that type. Furthermore I
> thought, that using <Self> whould propagate the actualy type
> at runtime
> time (which if on the second thought of course impossible for
> a static
> type system).

Yes. Var* is a standard naming convention I used in Strongtalk for
mutation protocols that have been factored from the read-only protocol.
The convention is this: the read-only protocol generally gets the
obvious short name, like Assoc, because read-only protocols are (and
should be) the more commonly used, default protocol.  Then, if you want
the full mutation protocol, you just add a Var prefix.  The convention
works this way because using the read-only protocol whenever you can
makes your code more flexible.

> You say that with some experiences, the type system is easy to
> understand.  While most declarations are pretty obvious, I find it
> difficult to get some of the tricks (The typing of #perform: for
> example).  Unfortunately, when following the tutorial or doing some
> experiements, the system crashes very often, throwing "This
> should not
> happen" errors :-(

The typing of perform is just a stupid trick to force there to always be
a type error on any call to #perform: that doesn't have a guarantee.  I
just did this to force people who are trying to use #perform: to be
explicitly aware that they are taking over responsibility from the type
system.  Perhaps I shouldn't have done that, but I wanted people to
understand clearly when they are crossing the boundary between typesafe
and untypesafe code.  #perform: should not be a commonly used method in
typesafe code, in any case, so the extra effort should not be
burdensome.  Note that the Strongtalk libraries use blocks instead of
#perform: in places where that is possible, which is more elegant and
typesafe than using #perform:.

As for the crashes, have you tried the suggestions in the
troubleshooting documentation?  Specifically, raising the invocation
counters (to say, 30000 or 50000), or even running interpreted, should
help with stability during experiments.  I apologize for the
instability.  The system was more stable back when we used it all the
time, but right before Sun released it, it had to be recompiled with the
latest C++ compiler, and that destabilized the system, and there was no
way to debug or test it further at that point.

> However, my feeling is, that I'd perfer an inferring type
> system which
> does not force me to specify all types of all local variables
> but infers
> theses types, just checking for incompatibilities.

As I think Gilad has also said, there is no reason why what you are
suggesting couldn't be done just fine with Strongtalk.  Our point is
that the inferencing you are talking about should be a tool in the
programming environment, not a part of the type system itself.  We
wanted to do this too, but just never had time to do it. Note that you
can already select subexpressions in Strongtalk and ask for their type;
it would not be that hard to write some simple inference tools that
would use the typechecker infrastructure to propagate subexpression
types where possible to try to figure out local variable types or return
types.

-Dave





More information about the Squeak-dev mailing list