Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.CS.UIUC.EDU
Newsgroups: net.lang.st80
Subject: Re: Typed Smalltalk
Message-ID: <9000009@uiucdcsp>
Date: Wed, 30-Jul-86 10:17:00 EDT
Article-I.D.: uiucdcsp.9000009
Posted: Wed Jul 30 10:17:00 1986
Date-Received: Sat, 2-Aug-86 01:31:28 EDT
References: <799@cit-vax.Caltech.Edu>
Lines: 54
Nf-ID: #R:cit-vax.Caltech.Edu:799:uiucdcsp:9000009:000:3211
Nf-From: uiucdcsp.CS.UIUC.EDU!johnson    Jul 30 09:17:00 1986


/* Written  3:56 pm  Jul 20, 1986 by <bob atkinson> BAtkinson@Xerox.com */
>The key thing that a type system adds is the
>ability to statically bind some of the method lookups.  Once this is
>done, then methods tend to look a lot more like classical language
>procedures, and become much more amenable to classical optimization
>techniques (code motion out of loops, tail recursion elimination, loop
>unrolling, array index factoring, etc...) Note that this is NOT in
>conflict at all with the current language or the current flexible
>progamming style.  One can treat type declarations soley as HINTS and
>allow the programmer to violate them at will but perhaps suffer the
>cost of decreased speed.

It seems to me that a compiler that treated type declarations as hints
would not be able to make nearly as many optimizations as one that performed
static type checking.  For example, a compiler should be able to detect
that most block contexts will never be assigned to any instance variable
and so the method contexts that created them can be allocated on a stack.
However, the method context is allocated long before the block context
is sent to an object, and whether or not the block context is assigned to
an instance variable depends on the class of the receiver.  I suppose that
the method could transfer its context to the heap at run-time, depending
on the class of the receiver, as in the Deutsch-Schiffman implementation,
but that does not seem optimal.  I would like to perform the same trick
with any object whose lifetime can be determined.

Type declarations as hints should work well for method arguments, since
the class of these variables cannot change during execution of the method
(except by a becomes:).  Thus, it should be possible to test their class
only at the beginning of a method.  However, an instance variable or a
local variable that is changed inside a loop will have to be repeatedly
tested.  It seems to me that a lot of possible speedup would be lost.
I would be glad to hear otherwise.

>b) Improve documentation for novice users.  A crude, ad-hoc, and 
>etherially (sp?) defined type system is already found in many of the
>class commments.  The default comment (at least in my ST image :-)) 
>provides templates for each of the instance variables and a place to
>describe the ``type'' of the variable.  A real type system could
>formalize this and be able to actually make use of the information.
>We have the added bonus that programmers unfamiliar with the class
>can get an idea of what the class feels like by looking at its type
>declarations.  This, coupled with the easy ability to browse any 
>reference to an instance or class variable gives a very quick way to
>get an idea of the purpose of any particular variable.

I've been teaching a lot of people Smalltalk, and it is clear to all
of us that a type system would make the system (not necessarily the
language) easier to learn.  In our image, at least, some of the
comments are wrong.  However, the usual problem is that there are
just not enough of them.  Types would provide additional information
that should make the system easier to learn.

Ralph Johnson johnson@cs.uiuc.edu or ihnp4!uiucdcs!johnson