nil or #nil?

Tim Olson tim at jumpnet.com
Mon Sep 21 14:40:37 UTC 1998


>Did this ever get resolved?

I don't think there was a final resolution on it, but this question 
raises the larger question of Pink plane vs. Blue plane.  Dan Ingalls 
wrote about this "pull" between the Pink and Blue planes in October of 
'97; here are some exerpts:

----
There are two strong forces at work in the Squeak team, which are often 
in opposition.  However we have managed to keep it together for long 
enough that it's probably adequate to articulate the two and you can 
guess at where equilibrium will take us.  These have most recently been 
articulated in Alan's allusion to Toffler's metaphor of progress in the 
pink (incremental improvement) plane and the blue (paradigm shift) plane.

The forces in the pink plane have to do with making an ever-better 
Smalltalk-80 system that can serve a wide spectrum of research and 
academic needs, while leveraging off the large body of ST-80 
documentation, existing code archives, and synergy with high-performance 
industrial ST-80 systems.  In this plane Squeak's high level of 
compatibility with the ST-80 language (and even with the MVC display 
architecture) is a plus, and the current forces of progress are aimed at 
a higher performance interpreter, with support for block closures, 
exception handling, as well as some answer to various needs for 
finalization.  There is an active crew, led by Iam Piumarta, working on 
the first two items, and we are holding a couple of solutions to the 
latter issues in abeyance until the new interpreter is incorporated and 
running stably.

The forces in the blue plane have to do with a completely different 
graphics model, evolution of the language model, and hopefully an even 
simpler yet more powerful language kernel.  Each of these constitutes 
significant change, and is thus at odds with various entrenched 
interests.  At the same time we feel that each offers significant 
benefits.  A fair portion of the new graphics model, based on the Morphic 
interface to Self is already running and can be explored in the Play WIth 
Me windows of the release.  While some parts of Morphic have not been 
honed to peak performance like other parts of the system, many are much 
simpler and yet more general.  With the next release you will see 
presentation graphics support such as drop shadows and gradient fills, as 
well as desktop publishing capabilities including linked text frames, 
text flow inside and around arbitrary shapes, and letter kerning.

To best understand the "blue" pulls within the Squeak group, you need to 
understand what we're after.  Our number one commitment is to an 
exquisite personal comuputing environment.  Imagine a system as immediate 
and tactile as a sketch pad, in which you can effortlessly mingle 
writing, drawing, painting, and all of the structured leverage of 
computer science.  Moverover imagine that every aspect of that system is 
described in itself and equally amenable to examination and composition.  
Perhaps this system also extends out over the internet, including and 
leveraging off the work of others.  You get the idea -- it's the Holy 
Grail of computer science.  All and everything.  So if some new approach 
comes along that takes us closer to that ideal, but at the cost of a 
break with ST-80 tradition, we will probably take the new approach.
----

So the stated goals of Squeak (from "Squeak Central's" viewpoint, at 
least) do not include 100% compatibility with other Smalltalks; in the 
future there will likely be larger divergences between Squeak and the 
ANSI Smalltalk standard.


To summarize from the "Pink Plane" and "Blue Plane" perspectives:

The "Pink Plane" fix would be to adopt the ANSI standard in this case, 
and have the reserved identifiers 'nil', 'true', and 'false' treated 
specially in literal array creation.

Some of the proposed "Blue Plane" fixes are:

1) explicit general evaluation
     literal arrays are created as they are now, but a special escape 
operator
     (##)? allows the insertion of any general expression, which is 
evaluated at runtime:

     foo := 25.
     x := #(foo ##foo 1 $b nil ##nil)

               x         ->        (#foo 25 1 $b #nil nil)


2) general evaluation with explicit non-evaluation
     literal arrays are created from a sequence of explicit literals; any 
non-literal
     is evaluated (runtime or compile time context?)

     foo := 25.
     x := #(#foo foo 1 $b #nil nil)

               x         ->        (#foo 25 1 $b #nil nil)


note that #2 is the same as the existing Brace construct in Squeak, with 
a slightly different syntax.




     -- tim





More information about the Squeak-dev mailing list