### <== Previous | Contents | Next ==>

## A Two-Page Introduction to the Strongtalk Type System

#### David Griswold

First of all, a clarification: the name Strongtalk, originally used in an OOPSLA paper in 1993, referred just to the type system, which was originally grafted onto what was then ParcPlace Smalltalk. The name was later adopted for a far larger system, which includes the optimizing virtual machine, new "Blue Book" libraries that have been completely reimplemented to accomodate a number of goals in addition to type-safety, a new user interface framework, and a programming environment, as well as a second-generation implementation of the type system. The two are distinguished by referring either to the Strongtalk "system", or the Strongtalk "type system".

You will see a lot of type annotations as you browse around the system. A complete introduction to the type system is far beyond the scope of this tour. Right now, I will give you a crude two-page summary of the type system. Don't get intimidated; just read it and the simple examples should make the basic ideas clear. Once you've finished these two pages, you can read just about any type annotation in the system and get the basic idea (A copy of a somewhat more detailed workshop presentation by Gilad on the type system is here). There should be some more formal documentation on the type system soon.

The main ideas to keep in mind are:

- The type system is based on declared support for protocols. Protocols can either be implicitly defined by a class interface, or explictly defined with a separate name (which is useful for keeping class-side messages out of the protocol, or other kinds of abstraction).
- All type expressions are delimited by < >
- All variables have a type annotation, so that method arguments, local variables, block arguments, etc are each followed by a <...> expression.
- It supports generic types, using the syntax SomeProtocol[TypeA,TypeB,...] This allows you to use types like <Collection[Str]> (Str is a declared alias in the the libraries for the the read-only string protocol ReadString, that both Strings and Symbols support. Unmutated strings are so commonly used that Str is a useful shorthand. Note that in the Strongtalk libraries, Symbols can be fully substituted for Strings, if you don't plan on modifying them, which doesn't work in some other Smalltalks). You can define both generic protocols and generic classes.
- Message or method return types are indicated with a leading ^, for example ^<Int> means a message or method returns an integer. I am using the words message and method distinctly because we declare methods in classes (implementations) whereas message just refers to the method's signature, which can also be declared in a protocol without a method body.
- Block types have their own syntax; for example the block [3] has the type <[^Int]>, meaning the block produces an integer (Int is a declared alias for Integer). Argument types come before that, separated by commas, so that the block [ :s <Str> | s size ] has the type <[Str,^Int]>, meaning it takes one Str argument and produces an Int. If you don't care about the value type of the block you can omit it, in which case it is Object by default.
- Here is a whole method so you can see how types are used:

      aMessage: aStringBlock <[^Str]> ^<Int>
          | result <Int> |
          result := aStringBlock value size.
          ^result

  This is a method that takes (a block that produces a Str), and returns an integer.

### Type System Intro (cont.) ==>