Self doesn’t have an exception handling scheme. That is, it doesn’t have the equivalent of Smalltalk, Javascript, Java etc where you can construct a try/catch structure and exceptions can be thrown up the stack until they find a suitable handler.

This is at least in part because no one has written one – Self certainly is flexible to accommodate a Smalltalk style exceptions system. But it is also a matter of choice. Instead of exceptions, Self encourages the pattern of passing an exception handling block to methods that need it, so an openResource method could become openResourceIfFail: [|:e| doSomthingElse: e ]

Changing this would be a reasonably serious task. Exception systems are tricky things, which can cause confusion. They introduce complexity, and I’m not convinced (at least at the moment) that their benefits outweigh the added complexity. (If you want to convince me, a good way would be to write a nice idiomatic Self exception handling framework 🙂 )

But this certainly doesn’t mean that we can’t improve how Self handles exceptional circumstances.

One area of annoyance with the current setup is the error: message. Very similar to the old Smalltalk-80 mechanism, sending error: to most objects results in the process in question being suspending, and a debugger opened in the morphic desktop or on the command line interface.

Try getting 9 / 0 or doing error: 'Error' to see what I mean.

This is necessary. Despite good intentions, there will always be situations where things break. But sometimes this isn’t the error handling behaviour that we want. For example, in a testing framework we want errors in our tests to be logged, not immediately debugged.

How to improve this? I’ve uploaded to Github a patch under an experimental error-handling branch. You can read the diff online. In summary what it does is:

defaultBehavior implements two important methods regarding errors.

The first is the method handleError: error , which takes as its argument an error object. Prototypes for different error objects are found in processErrors.

The second is the more usually called error: errorString method, which takes a string description of the error and creates an error object and calls handleError:

handleError: in turn calls the errorHandler code on its process object which sends the error object to the currently selected error handler, which could be a block or an object understanding value:

Some default error handling objects can be found in the errorHandlers global. They include the default handler (which opens a debugger), the silentSuspend handler which silently suspends the process, the silentAbort handler which aborts the process and the returnNil handler which always returns nil.

A handler can be installed by calling process this errorHandler: myNewHandler, but this is not recommended.

Instead, you should call [ myCode ] onError: myNewHandler which installs the handler, runs the block and then cleans up after itself by reinstalling the original handler.

As well, there is a global called raiseError, which is the equivalent to [|:e| error: e ] and can be used in similar circumstances: something ifTrue: raiseError

This is *not* an exception system, despite its surface similarity. It does not deal with the stack or dispatch errors differently based on error type. It is not intended to be used for anything except situations where you need to change from the default behaviour of opening a debugger. The encouraged way of handling exceptional circumstances continues to be to pass an exception handler to the method which may require it. On the plus side, it is clean, simple and doesn’t require a lot of explaining.

What do you think about this approach?

The Self handbook, which contains most of the documentation for the Self project, has been available for a while at http://docs.selflanguage.org in html for online reading.

Now I’ve managed to build a PDF version, which can be downloaded for offline reading.  It’s 150 pages long and contains a lot of useful information to ponder and inwardly digest.

It’s built though Sphinx and LaTeX. I looked around for alternatives to LaTeX, because I find it a pain (especially when dealing with large tables) and was fascinated to see that (despite the obvious problems with it) there isn’t a clear replacement . Oh well.

One of the strengths of Self is the number of great published papers that were written by the Self team at Stanford and later at Sun.

We’ve been trying to collect all of these on the Self website on our published papers page – you should really check them out.

Recently John Maloney sent me a paper of his and Randy Smith’s on Morphic from 1995, which I’ve added to the list. It’s called “Directness and liveness in the Morphic user interface construction environment” and its worth reading for the philosophy and structure behind Morphic, Self’s main user interface and its later incarnations in Squeak/Pharo and Dan Ingall’s Lively Kernel.

It has been decreed that it is high time Self joined the Great League of Important Programming Languages (TM) and organised its own IRC channel on Freenode!

Yay!

Anyway, if you have any Self questions then pop on by Freenode channel #self-lang and visit us.

We promise to be friendly, if not necessarily coherent.

Introspection is Self observation, which makes sense because in the end computers are more about us than anything else. At the end of 2010, it is time to take stock of ourselves, considering what has been done (and not done) and prepare for the inevitably ignored New Year’s Resolutions.

For those who have just arrived at the party

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. – Dan Ingalls

Self is Smalltalk, only more so. – David Ungar

In our vision, the Self programmer lives and acts in a consistent and malleable world, from the concrete motor-sensory, to the abstract, intellectual levels. At the lowest, motor-sensory level of experience, objects provide the foundation for natural interaction. Consequently, every visual element in Self, from the largest window to the smallest triangle is a directly manipulable object. – Randy Smith

We live embedded in sensory experience and we act and respond to more than just rational discourse; the software worlds we build need to reflect that.

The Self environment attempts to provide an integrated intellectual and experiential computing narrative for supporting collective and individual creativity. Self is not only about personal computing but also collaborative computing.

The main story that Self tells is that everything is an object and objects respond to messages. Self thinks of objects as being made of slots, each with a key and a value. If the value is a method, then when a message that is sent to the object matches that slot, the method will be run. Objects can share slots by delegating message lookup to each other.

Messages in Self (and hence Self’s syntax more generally) follow a modified version of Smalltalk’s keyword based syntax.

Self comes with a user interface, morphic, which attempts to make objects visually concrete entities which can be physically manipulated.

Self currently comprises a fast VM written in C++ for MacOS X and Linux x86, together with text sources in Self which can be compiled by the system. The runtime state of a running Self system can be saved in a snapshot, like a Smalltalk image.

The story so far

They always say that time changes things, but you actually have to change them yourself. – Andy Warhol

Since this is the first introspection, we should begin the tale in the heat of the summer of January 2009 when the selflanguage.org website went live.

In the last two years, we have begun to reinvigorate the Self community. Self now has a website, a more active mailing list and a blog.

Documentation has been consolidated into the Self Handbook, and old Self papers have been converted from PS to PDF and made available on the website.

The Self source code, including both the standard objects and the C++  source for the VM, is now available on GitHub.

David Ungar’s port to Linux has been finished off, and Self 4.4 has been released with prebuilt VMs and snapshots for Mac OS X and Linux x86.

Speaking of David, he was the deserving recipient of the Dahl-Nygaard Senior Prize for 2009 for his body of work, including Self.

Why we do it

I am glad you have a cat, but I do not believe it is So remarkable a cat as My Cat. – TS Eliot

Despite such JavaScript wonders as Dan Ingall’s Lively Kernel, Squeak’s ongoing improvements and Gilad Bracha’s NewSpeak, we believe that Self still has a place in the computing multiverse. We have a foundation of a good VM and a solid object model. We believe that Self is not a bad place to start if you want to invent Self.

Blue and Pink

Einstein’s space is no closer to reality than Van Gogh’s sky. – Arthur Koestler

Back in 1998, the old Squeak Central talked about their changes and aspirations based on an allusion to Arthur Koestler’s metaphor of progress in two planes: the incremental improvement plane (which Alan Kay dubbed the “pink” plane) and the paradigm shift (or “blue”) plane.

The pink plane for Self is made up of those improvements needed to get Self to the point where we can seriously start building the infrastructure needed to attract people who want to use Self for industry, academic or research uses. Examples of large pink projects include a Windows port, an ARM port and Unicode support; smaller pink projects include a proper unit testing framework, a proper streams library and a webserver.

Ideas which aim to make Self more like itSelf live on the blue plane. It is lucky that planes are unbounded, because blue ideas are legion. Some examples:

• Since the Self syntax was devised, languages such as Ruby, Python and Haskell have shown that the old shibboleths of syntax are losing their grip on the collective conscious; Self’s syntax could be simplified and streamlined.
• Computers are no longer stand alone entities; interworld communication would support greater collaboration and integration with other Self worlds, and other non-Self resources.
• The old fears of the Smalltalk image linger but programmers throw VMWare and VirtualBox virtual machine images around like lego blocks; building an object storage facility into the snapshot could make Self worlds more self-contained and flexible.

We may or may not do any of these.

April is the cruellest month

OK, enough hype. – Larry Wall

Since its exile from the warmth of the Sun into the wasteland of Open Source, Self as a project has been without a central core of people paid to get things done. But wastelands aren’t really. We’re actively seeking people to collaborate: if our goals resonate with you and you want to help out then get in contact.

However this early period of revival is bound to be slow and hesitant. Bear with us – or even better, join us!

For all the fish

Finally, the thanks: Firstly to Randy Smith and David Ungar, the parents, and all the team at Stanford and Sun in the olden days, and to Adam Spitz, Jan-Paul Bultmann and Chris Double for their contributions to Self’s reawakening.

‘Til next time, Russell

Most modern Smalltalk80 implementations have more or less converged on a standard exceptions framework as set out in the ANSI spec.

There’s a description here (it’s for Pharo, but is more or less the same as for Squeak, GnuSmalltalk etc)

Self doesn’t have an exceptions framework. There is a generally available ‘error:’ message, whose meaning is globally defined; apart from that there is a preference for passing error handlers to methods which are likely to need them (such as ‘at:IfAbsent:’ or ‘do:IfFail:’).

Is this enough?

An ANSI Smalltalk style framework should be doable. The core mechanism is winding up the stack and searching it for a suitable handler, which shouldn’t require any adjustment of the VM. The question is whether we want to.

The plus side is that ports of open source Smalltalk80 code might be made easier. For example, both SUnit and the new Xtreams stream library have built exception handling into the way they do things.

However, even if we adopt the idea of resumable exceptions, our framework would be likely to be different. The ANSI system is class based and relies on hierarchies of exceptions, where an EndOfStream signal is a subclass of an Exception which is a subclass of Error (or vice versa)

For Pharo this looks like:

Blimey!

This of course leads to the well known code pattern of:

| result |
result := [(StandardFileStream oldFileNamed: 'error42.log') contentsOfEntireFile]
    on: FileDoesNotExistException
    do: [:ex | ex fileName , ' not available'].
Transcript show: result; cr

This feels rather unSelflike (unselfish? unselbstlich?). It relies on the identity of objects to determine what happens to them, and also their class membership – confusing the object’s name (ie the path to the object from the lobby) with the object’s identity and behaviour and using a deep class hierarchy as an adhoc pattern matching mechanism.

Part of what I would like Self to do is to move away from unecessary reliance on the lobby as a guarantor of identity, and adopting a rigid lobby based mechanism for determining exception behaviour  wouldn’t help.

If the standard class based ANSI exceptions framework is not suitable for Self, what are the options? Is a stack searching resumable exception framework something which should be aimed for at all? Or should the concept of passing exception handlers to objects be explored further?