Squeak Starter

John Sarkela sarkela at cox.net
Wed Oct 16 21:17:17 UTC 2002


Hi gang,

After a year away from Smalltalk I have come back to the light.
Still catching up on all the changes... phew quite a task.
Still much of the chatter reminds me of my reaction to
Les Miserables... "such a lot of fuss over a piece of toast!" ;-}>

On Wednesday, October 16, 2002, at 07:32 AM, goran.hultgren at bluefish.se 
wrote:

> I am not so sure - Ginsu is a model describing Smalltalk source code -
> separately from the Smalltalk model itself. At least that is my
> understanding. Modules is instead an extension to the Smalltalk model 
> of
> classes. Way back when I talked with Henrik about this I found his
> arguments and model much more appealing than having an "extra" model
> like Ginsu.

Well, you have missed the key distinction. "Ginsu" was about a 
declaration
of the model of the semantics of a Smalltalk program. A non-reflective
description language of a reflective execution environment. The 
essential
distinction is the separation of the declaration from *any* 
implementation
of the semantic model specified. This first distinction is the key to 
allowing
the revision of the state of a Smalltalk program... independent of any
particular image or runtime implementation.

The draft of the ANSI Smalltalk standard v1.9 has sidebar comments that 
go into
some detail in this regard. Also, OOPSLA '88 Alan Wirfs-Brock and Brian 
Wilkerson
wrote the seminal paper on Modular Smalltalk which is the mother of
the ginsu approach to Smalltalk modularity.

<aside for the interested reader>
This subtle distinction is a profound one when considering the 
evolution of form.
(cf G.-Spencer Brown "The Laws of Form") Follow all the injunctions, 
contemplate
the declaration of formal indication, the consequent arithmetic and 
algebra
and finally the introduction of formal self reference in a form that 
experiences
temporal evolution of signal.
</aside for the interested reader>


>
> For example - the ability to have classes loaded in the image (fully
> compiled etc so that tools work and so on) but not having them 
> activated
> in the name space seemed like a brilliant approach. And activation
> through  big become-operation seemed very neat.
>

How is that distinct from having tools that operate on declarations of 
the
program with all methods fully compilable and loadable? At Digitalk,
Steve Messick did some very cool remote development on headless
images. Utilities like "cp" could be as small as a 30k image, with the
capability of attaching the program to the declaration giving full debug
and development support. (Imagine programs being a kind of project
with a completely separate namespace living in a separate runtime
process somewhere on the network... all with development ui's switchable
the way in which we switch between projects.) That is my definition of 
neat.
OBTW, the development environment itself was just another program...

> I talked with Henrik about Ginsu and he said that he had looked at it
> and thought that similar goals could be achieved better using other
> techniques. And then he wrote Modules. Since he knows this stuff
> infinitely better than me (especially compared with Ginsu) I can only
> hope he posts his thoughts.
>

Perhaps that is indeed the case. Nevertheless, dig up a copy of VSE if
you can. Load Team/V. Open a standard class browser and edit away.
Use the disk browser and file in a bunch of module unaware code.
All of that stuff winds up in a module called, *Unpackaged*. Most folks
never knew that the old fashioned browser was no longer editing the
classes and methods themselves, but instead declarations of the 
aforesaid.
I suppose my point is that all of this is based upon many years of
experience with making Smalltalk more modular.




More information about the Squeak-dev mailing list