[Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak

[Paul D. Fernhout]

Ian Bicking wrote:
> That's very hard to implement...

Probably true, at leas to do it in a  human readable way.

> For instance, imagine the user does this:
> 
>   x = [1, 2]
> 
> Then they get a handle on that [1, 2] list (we'll call it OB1) and do 
> "OB1[0] = 5".  How do we represent that as source?  Because they are 
> acting on actual objects, not bindings, and OB1 doesn't have any name, 
> nor will it exist at the same address in a second run of the program.
> 
> In order to turn this into source, you'd have to keep track of how you 
> can repeatably get to OB1 (I guess you'd see that it was named "x" 
> through source introspection?), and then translate operations on that 
> object into source that does operations on the path to that object.
> 
> I think doing this generally becomes infeasible, though you can get 
> close through successively more bizarre source code generation, until 
> you end up with something that looks like a Python-source version of 
> pickle, and even that won't work very well.

Just as reference to Squeak Smalltalk, it has a "changes" file that 
records each top level Transcript type interaction (equivalent to a Python 
shell in many ways) so that these can be replayed if you need to rebuilt 
an image from the last version you saved if there was a crash. That's not 
what I am proposing here.

But to address your specif example, maybe it does point to a paradigm 
shift. Is this what you would do in an interactive session for your example?
 >>> x = [1, 2]
 >>> OB1 = x
 >>> OB1[0] = 5
 >>> del OB1
 >>> x
[5, 2]
 >>> OB1
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
NameError: name 'OB1' is not defined

But, your "program" in terms of an image at that point no longer needs to 
assign "x = [1, 2]". What it needs to do, to get back to where it is, is 
assign "x = [5, 2]" if I understand your example correctly? Basically, 
there is a bound variable in some scope, and a value it is. As long as 
objects are reachable, we can write them out starting from roots of the 
system (class path, the stack, modules and globals, and so on). Anything 
we cant; reach should have been garbage collected anyway (though might not 
have with CPython's reference counting system). So, we recreate the 
binding and the object in as simple a way as possible, to make the objects 
that are part of the accessible system. (Might make sense to combine this 
work with a true generational mark-and-sweep multiple-spaces tenuring etc. 
garbage collection system for Python? :-)

Maybe I don't understand the example?  As I see it right now, while it 
might be interesting to have a change log about how objects got to be how 
they are now, what counts when saving an image to a Python *.py file for 
future reload would be just their current structure and the name bindings.

As a note, remember that if there was a line of program code somewhere to 
create an object using a class, using "x = [1, 2" that line would be 
stored and regenerated as part of the class being stored. The fact that 
creating a new object using an
   "test = Spam()"
would assign
   test.x = 1
is independent of the fact that in recreating test, we might do:
   test = object()
   test.__class__ = Spam   # can this work? fails with a TypeError
   test.x = 5
or, with some sort of optimizing storage system geared to writing 
human-equivalent code rather than doing things one piece at a time:
   test = Spam()
   text.x = 5
Again, though maybe I am missing something obvious here?

Now, there may be a lot of things to improve this. I like your "make" idea 
in that regard, and perhaps other ideas could help with that as well.

You are absolutely right in Python syntax defining how to create a set of 
objects being more than declaring a specific structure. Forth has some of 
the same aspects (only worse!). It is a big headache in many ways to 
analyze Forth (as opposed to Smalltalk or Java or plain C) but Python now 
has the advantage that this approach of using a Python program to save the 
state of a sea of objects is more feasible.

Obviously somewhere you are going to have some code with a lot of 
declaration of temporary variables and deleting them for complex 
manipulation on structures. Perhaps this could require sort of engine to 
optimize how to do that in a human readable way, sort of like an 
optimizing compiler? A big task, but potentially doable for people who 
like that sort of thing.

--Paul Fernhout