Alan Kay Alan.Kay@squeakland.org wrote:
It's "just like" LISP -- from which it got these sharing ideas long ago in the 60s (even before Xerox PARC Smalltalk). OOPs are simple views of an object (they "show" the entire object).
Hi Alan,
Does LISP or other systems have a history of using less simple views on an object? I am researching the impact of extending message sending semantics to include an eventual-send->promise->resolve style. Do you think it will be difficult to intuitively interact with objects that don't return values immediately? It is sometimes, especially with inspectors which expect strings back *now*. :) Aside from those issues, I am exploring the feeling of interacting in that kind of sending environment. Would it behave in a way that users expect? A related meta-question I have, is what features are required for interaction to be intuitive?
I'll attempt to briefly and clearly explain eventual sending. Please excuse me if I fail at that task.
I am building the promise-based eventual send mechanism of Elib, in Squeak (http://www.erights.org/elib and especially http://www.erights.org/elib/concurrency/msg-passing.html). This extends the immediate-call->return style of squeak message-sending to an eventual-send->promise->resolve style of message sending. Eventually sent messages are not executed immediately. This type of eventual reference returns an object reference, as a promise, to which you can eventually send additional messages, each returning a new promise reference.
These messages, sent to the promise reference, are pending until the receiver promise resolves to a real object reference (#become:), then the messages are eventually forwarded to this resolved object, and in turn each of their promises resolve, und so weiter. It is remarkable to me that separating the message sending from the method execution, results in small sequences of pending messages queued for those promise resolved objects.
These eventual references (objects or promises) are currenly compromised, as there are a few areas in squeak where the environment expects immediate values returned.
generally speaking, thank you for the opportunity. :) Rob
Cheers,
Alan
Rob Withers wrote:
Eventually sent messages are not executed immediately. This type of eventual reference returns an object reference, as a promise, to which you can eventually send additional messages, each returning a new promise reference.
These messages, sent to the promise reference, are pending until the receiver promise resolves to a real object reference (#become:), then the messages are eventually forwarded to this resolved object, and in turn each of their promises resolve, und so weiter. It is remarkable to me that separating the message sending from the method execution, results in small sequences of pending messages queued for those promise resolved objects.
These eventual references (objects or promises) are currenly compromised, as there are a few areas in squeak where the environment expects immediate values returned.
If nothing else, this LazyObject sums up my understanding of promises. Well, at least what I understood when I first read this post. It won't magically queue up messages, but it can be passed into other LazyObjects to stack up a flurry of last-moment resolution.
Read LazyObject>>doesNotUnderstand: to see how to crash the VM (at least on linux, fresh CVS+3.2-4743, VMmaker 5.5).
"The secret to answering quickly is to not understand the question." - Confucius's hairstylist.
Ok, I think the solution to the crash is - don't use become:. becomeFoward: is much nicer, if only it were in ProtoObject. Soo, is LazyObject redundant with some corner of Squeak I haven't explored yet?
squeak-dev@lists.squeakfoundation.org