Originally published in PIE Developers magazine, July 1994. For information about PIEDevelopers, contact Creative Digital Systems at !"#$#%&'())*+*,-.$())*+$/012 or 415-6214252.

SELF and the Origins of NewtonScript
Walter Smith
Apple Computer, Inc.
wrs@apple.com
Copyright (c) 1994 Walter R. Smith. All Rights Reserved.
This is an introduction to the paper "Self: the power of simplicity", by Ungar and Smith.
When I joined the Newton group--then called the Special Projects Group--in 1988, it was stilla research organization. The product, whatever it might be, was a long-term goal, and we had
the now-incredible luxury of thinking about abstract problems and filling our file cabinets withpapers ordered from the Apple Library document service.
One of the problems that interested us in those days was choosing a language for Newton. We
knew it would be a big influence on the feel of the system, and it would have to be powerfuland productive if we were going to do all the things we wanted. Object-oriented languages
were just starting to enter the mainstream (even C++ was not yet the industry darling it istoday), and there were a lot of interesting new languages to learn about and evaluate. In
hindsight, actually, we became a little too distracted by choosing a language; this period of
Newton history is not-so-fondly remembered as the "language thrash".
SELF stood out among the languages we saw during that period. Although it was clearly
impractical as a system language (it took several years for the SELF compiler to reach its
present impressive state), its audacious simplicity made an impression that the more "serious"
languages did not. During the language thrash, as we conducted a series of objectiveevaluations that showed we should really be using Smalltalk, or Eiffel, or Trellis-Owl, or even
C++, the conversation would often wishfully turn to SELF.
I had no idea I would end up designing a language for Newton. In fact, at that time weconsciously avoided the temptation to design a Newton-specific language. Leave language
design to the experts, we thought, and we'll just choose one.
To make a very long story short, it didn't happen that way. Reality set in, and during thedevelopment effort that brought you the MessagePad, a new language--now called
NewtonScript--evolved in parallel with the view system and object store. The language thrash
made it possible: all those languages we looked at provided a wealth of ideas that found theirway into NewtonScript. SELF was one of the primary influences.

SELF and NewtonScript

As a NewtonScript user (which I assume you are or will be shortly), you may not immediately
recognize SELF. NewtonScript is not a direct derivative. However, SELF inspired some of themost important aspects of NewtonScript.
The prototype-based inheritance system of NewtonScript is adapted from SELF's "parentslots"; it's more complex than the version of SELF described here, but simpler than some later
versions. Newton's view system evolved in parallel with NewtonScript, and the idea ofcombining container inheritance defined by the view hierarchy with refinement in the form ofview templates was naturally reflected in the language as "double inheritance". Later versionsof SELF allowed any number of prioritized parent slots, but NewtonScript fixed the numberand priority in the form of _parent and _proto slots.
The advantages of prototype-based inheritance are described somewhat abstractly in thispaper. As a user of Newton Toolkit, you experience them frequently. When you draw a view inNTK and attach slots to it, you're not specifying parameters that will be read out of a resource
file at runtime to generate an instance of a class that you specified somewhere else; you'reconstructing an actual object that will be embedded in your application and used directly atruntime. Eliminating that layer of abstraction gives Newton programming an unusually direct
feel. "One-of-a-kind" objects are painful to create in a class-based system, as Ungar and Smithpoint out, and graphical user interfaces are full of them.
SELF combines variables, slots, and messages into one mechanism, but NewtonScript doesn't
go quite so far. In SELF, you can't tell if referencing a variable will execute a method or just geta value from a slot. In NewtonScript, variable accesses are always simple slot accesses. If you
want to execute a method, you have to send a message. There's no fancy theoreticalexplanation for this decision; I was just being conservative with space,time, andimplementation complexity. The feature is sufficiently useful that it found its way into thesystem anyway, in the form of the SetValue function.
SELF's use of regular objects as activation records is a powerful idea. The NewtonScript
documentation avoids such a direct description of the calling mechanism because we find very
few people are interested in such details, and in fact the demands of speed draw theimplementation away from such a direct approach, but here you can see the elegance of theoriginal concept. Its original implementation in the NewtonScript interpreter may well havebeen smaller than its explanation.
It will be obvious that none of SELF's syntax was used in NewtonScript. Smalltalk syntax iselegant, but unfamiliar to most programmers. NewtonScript's Pascal-like (or, to give credit
where due, Algol-like) syntax is easier to learn for many, with little loss of expressiveness andpower.

Modern SELF
Active development continues on SELF, so if you find it interesting, there is more you willprobably want to read. If you have access to the Internet, visit the SELF archive for the latest
information on SELF.
Walter Smith joined the Newton group in 1988. He is the principal designer and implementor

of NewtonScript and the Newton object store.
wrs@apple.com, 8 July 1994