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

[Paul D. Fernhout]

Ian-

Maybe we are still thinking about different things here.

I'm going on the presumption that Python, like Smalltalk, have various 
"roots" which are things like (in Python) the loaded modules, the active 
threads and their stacks, and perhaps some other state. A Python world of 
objects is defined by these, since if any Python objects exist but are not 
reachable somehow, they can't effect the system. As I reflect on that, I 
can see how in theory outside forces that get a handle into object memory 
might make changes and such things might exist in other processes or 
threads, but that would just be a broken VM (or VM abstraction) to me more 
than a problem to solve. :-)

So, going on this assumption that all Python objects of interest are 
reachable from these roots (even if some of the roots themselves might be 
only known to the VM, like the current thread?) then a recursive procedure 
can flow down through from these roots and write one big text file 
consisting of mainly:

# big module
import lots_of_stuff
temp1 = object()
temp1.__class__ = Point
temp1.x = 10
temp1.y = 20

temp2 = object()
temp2.__class__ = Point
temp2.x = 40
temp2.y = 50

temp3 = object()
temp3.__class__ = Rectangle
temp3.origin = temp1
temp3.extent = temp2

modules.mymodule = object()
modules.mymodule.__class__ = Module # or whatever?

modules.mymodule.myrect = temp3

And so on. Now obviously this gets tedious, so an optimizing writer would 
instead produce:

# module mymodule
myrect = Rectangle(Point(10, 20), Point(40, 50))

But that's a matter of a smart writer, which I think is doable. Just think 
of it as like optimizing code (although maybe in reverse. :-)

Now the problem you point out, that there may be several ways to reference 
an object is obviously a real one. But a smart writer should handle that 
(with a little handwaving by me. :-) But essentially, like with pickle, 
the writer would know it has to write the definition for a function out 
somewhere, and so it would pick a good spot, and then other references to 
that function could refer back to the first place it was defined. (Or it 
could be put in a temp variable which was later deleted after it was done 
being used.) Even if the writer picked a bad spot, the problem would only 
be that the code looked harder to read and understand, not that it would 
not recreate the same objects in memory that were written out (though 
perhaps at  different locations; I'm presuming that would not matter -- if 
it did, then that might be a problem requiring VM changes or some fancy 
object creation order footwork, which would almost certainly mess up the 
code's readability). As I've just casually glanced at the CPython VM 
source code, and only just a bit more at the Jython code, I don't know 
enough off hand to see whether there might be other bigger problems.

Anyway, I still don't see a show stopper (unless it is specific object ids 
or exact memory locations being important -- perhaps affecting dictionary 
hashes or some such thing?). Difficulties yes, maybe painful ones, but no 
showstopper so far as I can see to writing out running code as Python 
files (again, unless the above object ID issue).

I can see that nicer source will likely result from tracking commands as 
the user defines them, as you suggest. But still, my focus isn't on 
readable source. That's more a nice to have feature from my set of 
priorities for GUI oriented construction and programming. What I am more 
interested in is, can the running program be changed, and can the changes 
be saved so they can be reloaded? So, our priorities may diverge there, 
but that's OK -- makes life interesting. :-)

--Paul Fernhout

Ian Bicking wrote:
> Interactive sessions are source.  The OB1 I referred to is the actual 
> object in memory, which has no real name, though it can be referenced 
> directly in memory.
> 
> Maybe a better example is something in HTConsole right now.  Any 
> function you can get your hands on in HTConsole is editable, in-place. 
> So you can do:
> 
>   >>> import random
>   >>> random.choice
> 
> And you'll get a form that shows the source to that function, and lets 
> you edit it.  That works fine in-memory.  But saving that is hard.
> 
> There's actually lots of ways to get access to a function.  When you get 
> random.choice, you are actually getting access to a method of a 
> singleton stored in the random module.  When you edit that, you are 
> editing the method.  How do you represent that edit as source?  Do you 
> see that the function is available as random.choice.im_func, or 
> random.Random.choice?  Or a property, which might be available as 
> SomeClass.some_property.fget.  There's lots of paths to functions, and 
> the function alone doesn't necessary know how to get to it.  And 
> functions are relatively easy; other objects can be much harder...
> 
>    >>> items = range(5)
> 
> The contents of items cannot be edited in place, because they are 
> recreated dynamically.  They can only be modified by later commands.
> 
> Keeping a log of commands is possible.  But you aren't editing live 
> objects anymore, except perhaps an illusion of that.  Instead you are 
> generating saveable commands from a specific location, which are 
> immediately executed to give you feedback but also saved so they can be 
> replayed in the future.
> 
> As I've been thinking about this, I think command generation is pretty 
> much like direct source modification, but direct source modification 
> also leads to nice source.  So that's why I'm thinking that live objects 
> isn't a good metaphor, after going down that path some.