🚀 go-pugleaf

I am working with Ralph Johnson on building a type system for Smalltalk-80,
and we have run into some problems.  (By the way, we are running Smalltalk-80
on the Tektronix 4404.)  Most of the difficulties arise when we attempt to
add instance variables to classes with many instances (e.g. ClassDescription,
MethodDictionary, etc.).  In the case of ClassDescription, we tried to add
an instance variable which required that every class be recompiled.  When the
system was about half done with this recompiling we started getting "Low On
Memory" warnings.  Plodding on undaunted we eventually got thrown out of the
Smalltalk interpreter with the message: "Smalltalk system error - Too many
objects."  When we tried to add an instance variable to the class MethodDiction-
ary we encountered a quite different problem.  MethodDictionary was recompiled
with no problem, but then the "updateInstancesFrom: oldClass" message was sent
to the class description for the new class (MethodDictionary).  This involved
"recreating any existing instances of the argument, oldClass, as instances of
the receiver, which is a newly changed class."  The following message appears
in the method,

	oldClass allInstances do:
		[:old | ...
		old become: new]

The "allInstances" message yields a collection of all the MethodDictionaries
in the system.  These are then updated one at a time, as "new", and then the
object pointers are swapped with the "become:" message.  The problem occurred
when "become:" tried to swap the object pointers for the MethodDictionary that
contains the definition for the "become:" message.  We are thrown out of the
Smalltalk interpreter with the message: "Smalltalk system error - recursive
DoesNotUnderstand:."

We have a suspicion that the interpreter may assume certain things about some
fundamental classes and that adding instance variables as described above may
be impossible.  It would be helpful if someone could confirm or deny this.
We have also considered using the system tracer to modify such large classes,
but feel that this may be an unreasonable solution.  Has anyone ever used the
tracer for such a purpose and is it feasable?  Unless these problems can be
solved, our present solution is to change the meaning of existing instance
variables (for example, a list could easily become a list of ordered pairs or
ordered triples) or to build each "new" class from scratch.

Has anyone come across these problems before?  Has anyone found any solutions?
Does anyone have any suggestions?  I would appreciate any information that
anyone thinks would be helpful, thanks.


		Justin Graver