The following is copied from the web page: http://spair.swiki.net/21 (which also contains screenshot). It thought it may be of interest to the people on this list.
------------- === Overview This change set adds delegation capabilities to the Squeak VM. It also extends some previous work on prototypes by Hans Martin Mosner to implement a Self-like (http://self.sunlabs.com) system within Squeak.
Delegation is the act of forwarding a message to another object, but maintaining the original receiver such that sends to self in the new method context will be directed back to the delegating object.
=== Screenshot The following screenshot shows ProtoInspectors open on a family (literally) of objects. They are arranged according to their inheritance hierarchy. Slots with an asterisk denote parent slots (their behavior is inherited by the child). The image doesn't show it, but you may have any number of parent slots.
<<see web page: http://spair.swiki.net/21%3E%3E
=== Implementation Details Two new bytecodes are added to the VM:
singleExtendedDelegateBytecode doubleExtendedDelegateBytecode (but the compiler has not yet been modified to generate these bytecodes)
Several new primtives are added to support delegation and reflection
primitiveDelegate - added to Object as #delegate:, #delegate:with:, ...etc primitiveDelegateArgs - added to Object as #delegate:withArguments:
The following primitives allow a Mirror to reflect on objects without needing to send messages to the reflectee (this allows mirror to manipulate objects that may have a very lightweight protocol):
primitiveGetSlots primitiveSetSlots primitiveGetProtoBehavior primitiveSetProtoBehavior
The message lookup algorithm is also modified to search the parent slots of objects whos class is an instance of ProtoBehavior. This allows for instance based, multiple inheritance.
Bytecodes accessing the internal structure of an object (pushReceiverVariable and kin) are modified such that the look to the "receiverStorage" object in the active context. In normal messages receiverStorage is identical to receiver, but in delegated methods, they will be different.
You may create object that inherit behavior from normal Smalltalk instances (direct instance variable manipulation will affect the parent object, not the child's slots).
Hans Martin Mosner's HmmProtoObject class has been dropped in favor of the Mirror class and a reflection based approach to meta- programming in the spirit of Self. To add or remove slots or methods, you must use a mirror (unless you add methods to your instance). The ProtoInpector now uses a Mirror to manipulate an object. This allows objects to be inspected and manipulated even if they have no behavior.
The VM has also been enhanced such that a recursive #doesNotUnderstand: will not crash the image, but lookup the #doesNotUnderstand: on Object (and you will get a #doesNotUnderstand: on a #doesNotUnderstand: message). This was done because the likelyhood of accidentally creating objects that don't understand #doesNotUnderstand: has increased dramatically with the introduction of ProtoBehavior.
There should now be enough support in the VM to implement a pretty robust implementation of Self within Squeak. It would be really cool to see the Self tools for manipulating objects recreated in Squeak.
=== Issues The compiler has not been modified in any way, shape or form to implement anything like the Self syntax. This means that doing certain things can be awkward. Additionally, this means that you must use #delegate: or one of it's variants in order to accomplish what Self calls a "resend." Also, only a directed resend is possible.
There is no way to store instance based source code, therefore, all methods appear in their de-compiled form. This is a pain.
=== Downloading There are three things that you can download:
1. A bundle that includes a demo image, changes file, and a Win32 VM 2. Just the change set (you will need to compile your own VM and follow the procedure below to get an existing image prepared to run on it) 3. Just the win32 VM (note, trying to run a base Squeak image on this VM won't get you very far very fast)
If you are going to compile you own VM, you will need to load the change set, and then execute the following code in a workspace to prepare the existing method contexts in your image:
MethodContext allInstances do: [ :ea | ea instVarNamed: #receiverMap put: ea receiver ]. Smalltalk snapshot: true andQuit: true.
Then, you should have an image that will work on your new VM with support for delegation.
Stephen,
great job!
I think that the missing piece (having the compiler generate the new bytecodes) isn't hard to do. But you would have to come up with a new syntax to express delegation and making it different from regular message passing would give it a significantly different feel from Self. I don't see anyway around this short of a total retrofit of Squeak, which isn't your objective, right?
One suggestion is to add a new keyword "resend" in the spirit of "self" and "super". Of course, that might be confusing if a message being resent is found in the object itself.
-- Jecel
--- In self-interest@y..., Jecel Assumpcao Jr <jecel@m...> wrote:
Stephen,
great job!
I think that the missing piece (having the compiler generate the
new
bytecodes) isn't hard to do.
No, not hard at all...but I'm not overly eager to work on that.
But you would have to come up with a new syntax to express delegation and making it different from regular message passing would give it a significantly different feel from
Self.
I thought that a resend in Self has a special syntax like "parent resend.someMessage" or something...is that not correct? In Squeak it would have to be "self parent resend.someMessage" or something along those lines. Right now, you can do "self parent delegate: #someMessage" ...if your parent implements #delegate:. I'm going to avoid getting into the syntax issues for right now.
I don't see anyway around this short of a total retrofit of Squeak, which isn't your objective, right?
Well...actually, that's not out of the question...one could retrofit the Squeak object format such that any object in the system can pick up new behavior (the current Squeak object format would be nearly identical to an optimized format in which an object has no unique behavior, and only one parent slot). Only a few bytecodes and primitives would need to change.
But, what I really need is a good (and easy) persistence mechanism for Squeak...which is what started me on this path (I needed a way to quickly bring in external objects, and become was not viable due to the lack of an object table...it worked out that delegation was the only clean solution). However, now that I understand a little more about the Squeak VM from implementing delegation...I think I may have a shot at implementing a virtual object memory for Squeak (instead of an external persistence mapping...thus eliminating the original motivation for the delegation stuff I just did).
I would like to see both things...a virtual object memory, and the ability to completely tailor the behavior of any specific object. Then I think multi-user capability would be within grasp (reflection primitives could be secured based on the active user, compiled methods could be secured with additional security information on the object in which it is to execute, etc). All of this could tie into SqueakNOS.
...well, one has to have dreams. :)
One suggestion is to add a new keyword "resend" in the spirit
of "self"
and "super". Of course, that might be confusing if a message being resent is found in the object itself.
-- Jecel
- Stephen
On Wednesday 22 August 2001 09:19, Stephen Pair wrote:
I thought that a resend in Self has a special syntax like "parent resend.someMessage" or something...is that not correct? In Squeak it would have to be "self parent resend.someMessage" or something along those lines. Right now, you can do "self parent delegate: #someMessage" ...if your parent implements #delegate:. I'm going to avoid getting into the syntax issues for right now.
Right! I was thinking about all messages to an object with automatic "delegation" and you were thinking about explicit delegation. The syntax is
resend.someMessage: arg
when you want to have the lookup in all parents (so this would be sort of like super in Smalltalk) and
parentName.someMessage: arg
when you want to restrict the search to a particular parent. I am not very fond of this syntax, specially since it makes "." do tripple duty (statement separator, resend and floating point).
I don't see anyway around this short of a total retrofit of Squeak, which isn't your objective, right?
Well...actually, that's not out of the question...one could retrofit the Squeak object format such that any object in the system can pick up new behavior (the current Squeak object format would be nearly identical to an optimized format in which an object has no unique behavior, and only one parent slot). Only a few bytecodes and primitives would need to change.
Ok. And it is certainly possible to run Squeak on top of Self like Mario did with GNU Smalltalk. I have been looking into this...
But, what I really need is a good (and easy) persistence mechanism for Squeak...which is what started me on this path (I needed a way to quickly bring in external objects, and become was not viable due to the lack of an object table...it worked out that delegation was the only clean solution). However, now that I understand a little more about the Squeak VM from implementing delegation...I think I may have a shot at implementing a virtual object memory for Squeak (instead of an external persistence mapping...thus eliminating the original motivation for the delegation stuff I just did).
I mentioned on the Squeak list some designs I have considered over the years for this. I don't think a consumer quality system is possible without it. Things are simply not automatic enough.
I would like to see both things...a virtual object memory, and the ability to completely tailor the behavior of any specific object. Then I think multi-user capability would be within grasp (reflection primitives could be secured based on the active user, compiled methods could be secured with additional security information on the object in which it is to execute, etc). All of this could tie into SqueakNOS.
....well, one has to have dreams. :)
They are best when they are shared. -- Jecel
I mentioned on the Squeak list some designs I have considered over
the
years for this. I don't think a consumer quality system is possible without it. Things are simply not automatic enough.
I'd be interested in hearing those designs...I'm working on a design myself...I've been reading the Kaehler's LOOM stuff and that's been very helpful in identifying the things I need to watch out for. I'm shooting for something that will make incremental persistence fast, and will provide a commit primitive that will ensure everything is on disk. Looks like the LOOM design would be expensive if you want to make sure everything was saved (requiring a scan of object memory I think).
Actually, I'm amazed that this hasn't been a higher priority with SqC...you really can't consider Squeak as an OS without a solution in this area. And, it's been done in so many other contexts...why not Squeak? Makes me wonder if there's something I'm missing?
....well, one has to have dreams. :)
They are best when they are shared. -- Jecel
:)
- Stephen
On Wednesday 22 August 2001 22:46, Stephen Pair wrote:
I mentioned on the Squeak list some designs I have considered over the years for this. I don't think a consumer quality system is possible without it. Things are simply not automatic enough.
I'd be interested in hearing those designs...I'm working on a design myself...
Well, it probably isn't worth cross posting here. I am not sure whether the thread should go on in the Squeak list either (in the thread "[Cross-space references] NewtonOS and Sessions"). BTW, I'll answer here a question you made there -
Would this work? Has it been done before?
Ian Piumarta is the right guy to ask about this. See
http://www-sor.inria.fr/projects/sspc/
There are other projects at SOR that are related to this as well.
I've been reading the Kaehler's LOOM stuff and that's been very helpful in identifying the things I need to watch out for.
Though LOOM was created to eliminate the problems with OOZE, it is worth knowing that system as well.
"Virtual Memory for an Object-Oriented Language" by Ted Kaehler pages 378 to 387 in Byte Magazine, August 1981, Volume 6 Number 8
I'm shooting for something that will make incremental persistence fast, and will provide a commit primitive that will ensure everything is on disk. Looks like the LOOM design would be expensive if you want to make sure everything was saved (requiring a scan of object memory I think).
You must scan the whole object table and flush any "dirty" objects back to disk. This is normally done in the background continuously, but you might have to force a full scan in order to commit.
I would consider the system created for the Mushroom project to be an evolution of LOOM:
http://www.wolczko.com/mushroom/index.html
See the garbage collection papers, specially the last one.
Actually, I'm amazed that this hasn't been a higher priority with SqC...you really can't consider Squeak as an OS without a solution in this area. And, it's been done in so many other contexts...why not Squeak? Makes me wonder if there's something I'm missing?
Too many virgin PhDs have been sacrificed to this dragon for them to undertake such a project lightly. I wouldn't say it has ever been done *right* in any other context.
-- Jecel
Stephen Pair wrote: ri, 31 Aug 2001 01:03:08 -0700
Dear Thomas:
I have redirected your message here because it is not my intention to knock any language. I want programming languages to be as good as the variety of languages around us! My favourite one is German for example!!! But I would like to know Chinese!!! The pupil of my eyes is biodiversity treaty!!!
This sounds great! Java has sort of these facilities. But to program in Java is rather nasty! I do not think I am being biased because I do need
to program with the prototypes!!!
Squeak doesn't have prototypes, but it's a nice system nonetheless. Give it a try.
Thanks to Stephen Pair Squeak has prototypes now!!Java thanks to Gunther Kniesel has prototypes too!!! All inspired in Self!!! Se Kniesel's Lava (Java + prototypes):
http://javalab.cs.uni-bonn.de/research/darwin/
He does a real nice job!!!
However, don't knock Java. Yes, it is more effort to get stuff done in it. On the other hand, when you are dealing with other people's code, the type checking and extra structure is really a blessing.
Yes , I understand everybody is striving to deliver more expressive, safe and efficient languages and unfortunately there is no formula to make a language that is all that at the same time but ecodesign models require this at light speed, thought travels at a speed higher than light says Jack Sarfatti in his Postquantum Mechanics!!! So I am sure mankind needs ecodesign modes at thought speed!! This is why I seem agressive!! It is my love for mankind!!!
Sustainably, Albertina
Cheers, Thomas.
The following is copied from the web page: http://spair.swiki.net/21 (which also contains screenshot). It thought it may be of interest to the people on this list.
=== Overview This change set adds delegation capabilities to the Squeak VM. It also extends some previous work on prototypes by Hans Martin Mosner to implement a Self-like (http://self.sunlabs.com) system within Squeak.
Delegation is the act of forwarding a message to another object, but maintaining the original receiver such that sends to self in the new method context will be directed back to the delegating object.
=== Screenshot The following screenshot shows ProtoInspectors open on a family (literally) of objects. They are arranged according to their inheritance hierarchy. Slots with an asterisk denote parent slots (their behavior is inherited by the child). The image doesn't show it, but you may have any number of parent slots.
<<see web page: http://spair.swiki.net/21%3E%3E
=== Implementation Details Two new bytecodes are added to the VM:
singleExtendedDelegateBytecode doubleExtendedDelegateBytecode (but the compiler has not yet been modified to generate these bytecodes)
Several new primtives are added to support delegation and reflection
primitiveDelegate - added to Object as #delegate:, #delegate:with:, ...etc primitiveDelegateArgs - added to Object as #delegate:withArguments:
The following primitives allow a Mirror to reflect on objects without needing to send messages to the reflectee (this allows mirror to manipulate objects that may have a very lightweight protocol):
primitiveGetSlots primitiveSetSlots primitiveGetProtoBehavior primitiveSetProtoBehavior
The message lookup algorithm is also modified to search the parent slots of objects whos class is an instance of ProtoBehavior. This allows for instance based, multiple inheritance.
Bytecodes accessing the internal structure of an object (pushReceiverVariable and kin) are modified such that the look to the "receiverStorage" object in the active context. In normal messages receiverStorage is identical to receiver, but in delegated methods, they will be different.
You may create object that inherit behavior from normal Smalltalk instances (direct instance variable manipulation will affect the parent object, not the child's slots).
Hans Martin Mosner's HmmProtoObject class has been dropped in favor of the Mirror class and a reflection based approach to meta- programming in the spirit of Self. To add or remove slots or methods, you must use a mirror (unless you add methods to your instance). The ProtoInpector now uses a Mirror to manipulate an object. This allows objects to be inspected and manipulated even if they have no behavior.
The VM has also been enhanced such that a recursive #doesNotUnderstand: will not crash the image, but lookup the #doesNotUnderstand: on Object (and you will get a #doesNotUnderstand: on a #doesNotUnderstand: message). This was done because the likelyhood of accidentally creating objects that don't understand #doesNotUnderstand: has increased dramatically with the introduction of ProtoBehavior.
There should now be enough support in the VM to implement a pretty robust implementation of Self within Squeak. It would be really cool to see the Self tools for manipulating objects recreated in Squeak.
=== Issues The compiler has not been modified in any way, shape or form to implement anything like the Self syntax. This means that doing certain things can be awkward. Additionally, this means that you must use #delegate: or one of it's variants in order to accomplish what Self calls a "resend." Also, only a directed resend is possible.
There is no way to store instance based source code, therefore, all methods appear in their de-compiled form. This is a pain.
=== Downloading There are three things that you can download:
- A bundle that includes a demo image, changes file, and a Win32 VM
- Just the change set (you will need to compile your own VM and
follow the procedure below to get an existing image prepared to run on it) 3. Just the win32 VM (note, trying to run a base Squeak image on this VM won't get you very far very fast)
If you are going to compile you own VM, you will need to load the change set, and then execute the following code in a workspace to prepare the existing method contexts in your image:
MethodContext allInstances do: [ :ea | ea instVarNamed: #receiverMap put: ea receiver ]. Smalltalk snapshot: true andQuit: true.
Then, you should have an image that will work on your new VM with support for delegation.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
-- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.
self-interest@lists.selflanguage.org
-
Albertina Lourenci -
Jecel Assumpcao Jr -
Stephen Pair