[Modules] Name space semantics was: Re: Some of my thoughts

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Thu Aug 16 12:10:23 UTC 2001


I have 3 things.

Stephen Pair wrote:

> One issue that has been raised from time to time is the idea of selector
> name spaces.  The idea being that methods could be added that are
> specific to some package, and can be easily installed and uninstalled.

I previously (off-list, not your fault that you didn't get it) argued that
we need to modularize the modularity effort itself, if we are to ever get
anything done. To do so we need separable, small, incremental steps. We need
to identify  the 'core' that must be done and should be done first.

I named selector name spaces as something to definitely be put off until we
have more necessary things.

The posting is at:

http://swiki.squeakfoundation.org/squeakfoundation/38

See that page for further ideas about what to do first.

Now, back to that core ;-)

Dan Ingalls wrote:

> There is a reason why I left foreign references interpreted.  It wasn't for
> the lateness benefit (ie perhaps changing the binding (but see below)), but so
> that we could *invalidate* the binding by swapping a module out.  This is one
> of the things that makes the Environments scheme sort of unusual.
> 
> The idea (and this all actually ran at one time) is that you can swap an
> entire Environment out as an image segment.  Then, since foreign references
> are of the form
> Envt Thing
> an attempt to refer to Thing will cause a message-send to the image segment
> root stub, giving Squeak a chance to swap in that segment and resume the
> message send.
> 

Dan,

your point makes good sense. Still, the present Environments scheme contains
an ambiguity, because it also allows inherited names, and these are not
late-bound. Ie. when you can write Thing directly it is early bound, but
when you write Envt Thing a message is sent. I think this semantic
inconsistency can lead to really annoying, unintuitive bugs in our code.
Particularly for inherited names, less so for names in the home Environment.

Indirection is preferrable as you indicate, but we should really be
consistent. So let's make all global references indirect.

In this way we may swat to flies at once. A current problem in Squeak is
indeed that globals are early bound. Eg. methods referring to a global need
to be recompiled to reflect that the golbal's value is changed. VW has
solved this by using a step of indirection, (possibly an association, Les
knows the details).

So if we make all globals late-bound we solve this problem as well. How
about, for Envt Thing compiling a message like now, but also do a similar
solution for 'direct' global references. Ie.

Envt Thing -> a message Thing sent to Envt,
Thing ->  a message Thing sent to the implicit environment,

where the implicit env. could be either the home env., requiring Thing to be
located at runtime, or it could be the env defining Thing at compile time,
avoiding the lookup at runtime. Again this is a trade-off against other
things. I think we can begin with the former.

In general my guesstimate is that global references are generally rare, and
do rarely occur in speed-sensitive places. Therefore we can avoid making
premature optimizations. If speed later turns out to be a problem, then we
optimize later.

PS. My Environmentalized 3.1 image crashes when an exception occurs (like
"self halt <doIt>"). _This_ is a hard crash, Göran. A problematic global
reference in the error handling code?


Andrew Black also raised the issue of having two ways of referencing
everything:

> Maybe I just don't understand what you were proposing.  I _thought_
> that you meant that every class would have two names, such as
> Root.OrderedCollection (in the root namespace) and
> Collections.Ordered (in the modularized namespace).
> 
> Note that it really doesn't matter whether the names are actually
> dotted names (very un-Smalltalk-like) or actually access paths, for
> example, Root and Collections might both be objects that understand
> orderedCollection and ordered as messages.  My objection is the
> cognitive overload (as a reader I have to mentally equate two things
> that are syntactically different) and the maintenance headache (we
> have to make sure that the two names/paths remain coherent forever
> more)

Right, this is a consequence of having both implicit and explicit foreign
references. As I mentioned, Wirth removed the first from Oberon, I kind of
dislike it too, in Occam's manner. But it is included in Allen's proposal,
it is widely used by other Smalltalks, and I don't think we can avoid it.

Note though that the implicit ref would never be Root.OrderedCollection but
simply OrderedCollection because you are inside the Root environment.

And because of these two ways of referencing, it may be a bad idea of having
Collections Ordered instead of Collections OrderedCollection.

This is the problem of backward compatibility. A clean start would let us
have elegant solutions, like Collections Ordered and Morphs Rectangle.

Henrik






More information about the Squeak-dev mailing list