[ENH] Symbol Spaces

Stephen Pair spair at advantive.com
Fri May 10 18:06:42 UTC 2002


I guess I should take a couple of steps back and explain a bit of the
motivation.  A while ago (8 or 9 months), I got interested in "selector
namespaces," which led me to a prototype implementation.  I found, much
to my surprise, that it was relatively easy to get method dictionaries
(and the tools) to work with keys other than symbols.  This in turn
allowed me to alter the compiler to generate messages that used
something other than a Symbol for the method selector (an instance of
Selector to be precise).  

I took that a step further, and created a separate "selector space" for
each Morphic project.  The compiler would compile instances of Selector
from a selector space local to the project (rather than instances of
symbol).  This allowed me to code within a project and be completely
isolated from the rest of the system.  I could, for example, rewrite the
OrderedCollection>>add: method, break it, and not take down squeak.  The
code I developed within the project would happily call my broken version
of #add:, but nothing else would.  Additionally, methods that were
changed or added in my project would be entered into the method
dictionary with the local Selector as the key (as opposed to the global
symbol).  So, it was trivial to be able to determine everything about
the system (in terms of methods) that I had modified within my project
(with the notable exception of changes in class shape).  A similar
technique could even be applied to class variables.

Getting back to your question...you seem to be attempting to figure out
how symbol spaces and modules would work together.  An important thing
to understand is that the code I released has no relation to the module
system whatsoever.  Well...except that I intend to use symbol spaces to
explore new ways of isolating modules from one another (but that is not
the only potential use for symbol spaces).

The example you give looks like you're showing how to access an object
stored within the namespace of a module.  This is sort-of the opposite
of what symbol spaces allow you to do.

Your example allows: objects to have similar names, but reside in
physically separate dictionaries
Selector spaces allows: objects to have similar names, but reside in the
same dictionary (and be kept separate of course)

It's really two ways to skin the same cat in other words.  There are
situations where having physically separate dictionaries is not an
option (or at least not easy)...method dictionaries is one example of
that.  You could implement namespaces in the Smalltalk system by keeping
a single global dictionary, but making the keys be LocalSymbols (instead
of global symbols).  I don't advocate that however.

There is also this tangential issue (and Henrik's favorite example)
about what to do with methods like String>>asUrl.  There are basically
three camps:

 1) those that would have you re-write this to be "Url
class>>fromString:" and would dis-allow String>>asUrl (saying that it's
poor design)
 2) those that think String>>asUrl is only acceptable if it is generally
useful (however, there is a flaw in this approach, what if the Url
module is not loaded?  What do you do in String>>asUrl if it's in the
Strings module?)
 3) those that think String>>asUrl is natural, and should be accomodated
somehow...even in the presence of a module system

In other words, the problem is complex, and the challenge is how to
effectively deal with that complexity (remember, complexity cannot be
removed, it can only be shifted from one place to another).

I think it's a worthy goal to attempt to allow one module define the
String class, and another module to define the #asUrl method.  Is it
possible to do in a clean and simple way?  I don't know, but it isn't
clean and simple in the current Smalltalk meta-model, or the current
state of the module enhancements to the meta-model.  I guess to some
degree, it all comes down to which of the following you find more
pleasant and natural?

  'http://www.yahoo.com' asUrl retrieve

      - or -

  (Url fromString: 'http://www.yahoo.com') retrieve

So...the current implementation of Symbol spaces:

 - allows me to play with further concepts in module organization
 - allows others to play with other String and Selector enhancements (by
pushing the protocol up to abstract superclasses that allow subclassing
for polymorphic substution anywhere a String or Symbol is called for)
 - reifies the Symbol class code for managing the global symbol table
into GlobalSymbolSpace
 - allows anyone who needs it to have a separate space for symbol
canonicalization

It's hard to describe this stuff in text.  I've had the best success in
getting the ideas across when I demonstrate being able to jump between
projects, change any code anywhere without regard to whether it's going
to crash the system, or conflict with another project, capture
everything that I change in the meta-model (as opposed to change sets,
which can easily get confused), having the code in various projects be
automatically active (without needing to push or pull things in and out
of method dictionaries (which also means that you could have more than
one project active at a time in a given image).

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Bergel Alexandre
> Sent: Friday, May 10, 2002 11:29 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [ENH] Symbol Spaces
> 
> 
> Hello Stephen,
> 
> First, thank you for being interested by modules.
> Module for Squeak need some motivated people.
> 
> Anyway, I admit I do not really understand what you have 
> done. What is different from :
> 
> (Module @ #(People)) addAssoc: (Association key: #test value: 
> 10) export: true.
> 
> 
> And if you have Test defined into module #(People), you can 
> perform this :
> Test>>foo
>   ^test
> 
> and what you have done ?
> 
> Regards,
> Alexandre
> 
> 
> On Thu, May 09, 2002 at 03:56:18PM -0400, Stephen Pair wrote:
> > The attached change sets should be filed-in in the following order:
> > 
> >   symspaces-preload.cs
> >   symspaces.cs
> > 
> > Note, due to very careful ordering of doIts in the preload, this 
> > change set will not file-out properly once filed-in.  These change 
> > sets were implemented (and tested) on a fully updated 3.3a image.
> > 
> > These change sets implement symbol spaces.  The following 
> changes are 
> > made in the String hierarchy (AbstractString, AbstractSymbol, 
> > LocalSymbol are new classes):
> > 
> > ...
> >   ArrayedCollection
> >     AbstractString
> >       AbstractSymbol
> >         LocalSymbol
> >         Symbol
> >       String
> > 
> > Additionally, the following two classes are added:
> > 
> > ...
> >   SymbolSpace
> >     GlobalSymbolSpace
> > 
> > These changes have the (not to be overlooked) side benefit 
> of making 
> > it easier to create classes that are polymorphically 
> compatible with 
> > String and Symbol.  Addtionally, Symbol now uses an instance of 
> > GlobalSymbolSpace to manage the global symbols.
> > 
> > To create a new symbol space and add a symbol to it, do the 
> following:
> > 
> >   SymbolSpace new intern: 'someNewLocalSymbol'
> > 
> > The idea behind these change sets is that they might eventually get 
> > used to do such things as:
> > 
> >   - implement a local symbol table for each module (just add an 
> > instvar called "symbols" to the Module class and have it hold onto a
> > SymbolSpace)
> >   - implement "Selector Name Spaces" by using LocalSymbols 
> as keys in 
> > method dictionaries
> >   - implement "Instance Variable Name Spaces" with a 
> similar technique 
> > (i.e. have a dictionary of "instvars" attached to an instance with 
> > LocalSymbols for keys)
> > 
> > SymbolSpace includes an "owner" instance variable to make 
> the lookup 
> > from a LocalSelector to the owner of the SelectorSpace quick if 
> > needed. Also, the refactoring might make other things (like Unicode 
> > support) a tad easier.
> > 
> > - Stephen
> > 
> 
> 
> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._
> Bergel Alexandre  http://www.iam.unibe.ch/~bergel
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^
> 
> 




More information about the Squeak-dev mailing list