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

Ian Bicking ianb at colorstudy.com
Fri May 5 18:22:15 CEST 2006


Paul D. Fernhout wrote:
> The key principles mentioned in movie for Self's design are based on ideas
> from the physical world, and are summarized as:
>    * Directness (everything is potentially visible and touchable)
>    * Uniformity (you can consistently change everything)
>    * Modelessness (always running, so no editing/running distinction)
> Self also demonstrates multiple people doing activities together in one
> (2D) environment. [BTW Neometron's Learningworks was about 3D communities
> using Smalltalk and was deployed a decade ago, which shows some other
> roots of Squeak/Croquet roots here.]

This is a little of what I intend with HTConsole; the objects are 
(vaguely) live, and potentially shared.  Though I've only implemented 
useful liveness for functions so far.  It's at conflict with the idea of 
source code, and live objects really require an image, and I've never 
liked images.  So I'm not sure if it's a useful path.

> Now this certainly isn't a new idea, see for example these discussions:
> http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html
> http://www.thescripts.com/forum/thread30832.html
> http://www.prothon.org/
> http://www.google.com/search?hl=en&q=Prothon
> or Prothon's apparent successor, PyCS:
> http://www.prothon.org/pipermail/prothon-user/2004-August/003269.html
> http://pycs.org
> [However, the Prothon and Pycs links seem to be down right now, I read
> them through the Google cache just now as this project is new to me,
> perhaps an indication the project is ended?]

As far as I know, the project fizzled soon after the move to CLR was 
announced.

> I want to underscore and emphasize this difference between these two
> philosophies of programming language design, because it seems that the
> directions proposed for mainstream Python, if anything:
>    http://www.artima.com/weblogs/viewpost.jsp?thread=86641
> have been in directly the opposite direction to Self, to a Python with
> static typing (including RPython). 

I wouldn't put too much weight on this, especially RPython.  RPython 
isn't meant to compete with Python in that way.  And it is Squeaky in 
its own way.

> Or, as Ian Bicking points out here in "Initial thoughts on Prothon":
>    http://www.artima.com/forums/flat.jsp?forum=122&thread=41588
> "[After mentioing Prothon syntax changes from Python...]
> I actually wonder to what degree prototypes could be implemented in
> Python with metaclasses. While some of the syntax would currently be crufy
> with Python (e.g., you'd have to create a function, then assign the
> function to an object), that's kind of a separate issue. The basic object
> model in Python feels like it should be replaceable, especially since we
> already have both new and old style classes. I think it's still a bit hard
> to think about these with the syntax getting in the way or otherwise being
> distracting, but feel like the potential is in there somewhere. If it
> could be hacked onto Python instead of developed entirely separately from
> Python, it could make Prothon much more interesting from the perspective
> of practical programming. Ultimately it would probably have to be like
> Stackless -- a patch against Python implementing some necessary changes to
> syntax. But that's a more viable development effort, and one that's more
> likely to percolate ideas into the main Python interpreter."

Some things other people have done (like Logix: 
http://livelogix.net/logix/) makes me think that this could be done in 
CPython now, with just some fiddling in the compile process.  I think 
the Python object model (which can't easily be changed) is already 
flexible enough for this.

And ignoring some syntactic details you could do this in current CPython.

> I think that Ian's suggestion is the most sensible strategy for proceeding
> in that direction and continuing to maintain community interest in a
> PySqueak inclined towards Self-like prototypes and a related GUI for
> constructivist educational use (and other general use as well).
> And if metaclasses turn out to not be the best approach,
> still anything simple which preserves the Python syntax
> while giving the new features (say, having all prototypes inherit from a 
> common class which overrides __getattr__ and __setattr__ to
> simply look into the instance to find data and behavior?)

I think it could be easier than that.  I think a lot of the more 
declarative programming I do really has prototypes underneath it. 
(Ironically in Javascript I never find a need for prototypes, except to 
simulate classes.)  An example:

   class Person(SQLObject):
       name = StringCol(notNull=True)

I think Person.name is really best represented as a prototype.  I've 
played around with using this:

   class Person(SQLObject):
       class name(StringCol):
           notNull = True

As an equivalent operation -- it starts looking better when you add 
methods to the object (e.g., on_delete, on_update, etc).  Actually 
having Person.name be a class is annoying, but you can get class 
statements to generate instances with some appropriate hackery.  At that 
point you start blurring the distinction between class and instance.

So, in this model, clone is the basic operation.  I.e.,:

   class obj(prototype):
       a = 1

Means something like:

   obj = prototype.__class__()
   obj.__dict__.update(prototype.__dict__)
   obj.a = 1

(The actual mechanics require some dumb fiddling with fake metaclasses.) 
  This is different from the delegation of a typical prototype language 
(where the prototype isn't copied, but is called back to), but it's fast 
and uses normal Python.  And I guess with clone in a prototype language 
you are basically doing this copy?  I'm more comfortable with copies 
than chains of delegation.

There was a proposal recently for a "make" syntax in Python 
(http://www.python.org/dev/peps/pep-0359/), so this would look like:

   make prototype obj:
       a = 1

And the exact semantics would be something like:

   obj = prototype('obj', (), {'a': 1})

Or my preference:

   obj = prototype.__make__('obj', {'a': 1})

Sadly Guido rejected it.  I think it's a much better syntax with cleaner 
semantics for this kind of case, and I think this kind of case is 
actually extremely common.  The whole Lisp S-Expr stuff is about this 
kind of declarative data structure, and adding that to Python just 
requires this little tweak of the language; it doesn't give Python 
macros, but the way Lisp uses data structures is for much more than just 
macros.  Smalltalk doesn't have anything like Lisp either, but uses live 
objects to some similar effect, which is what binds it to the image.

> Ian, any recent thoughts on that? I would speculate that part of the
> general interest of the world in HyperCard was that it to some extent
> worked in a direct-manipulation protype-based way. Perhaps that similarity 
> resonates with you as well?

I'm not really sure how to fit HyperCard into this -- I don't have a 
strong feel for what it really means.  I suppose one aspect is that the 
source code is not at the core; instead the card stack is (or whatever 
content-centric metaphor you use), and code is attached there.  Ad hoc 
structured code doesn't work that well with a class... you get something 
like:

   class Foo:
       def bar(self)...

   foo = Foo()

And the class/instantiation is just a kind of boilerplate.  OTOH, 
modules are another model; if each content-context (aka card) was a 
module, you get some of the structure without the conceptual overhead of 
the class.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Edu-sig mailing list