Hi Marcel,
Why are you -1 with PromisesLocal? It is easy to add the protocol published by the current Promise class, minus the wait protocols. I can certainly rename the proxies, as well. So what specifically are you -1 abut wrt PromisesLocal?
PromisesRemote is in addition to PromisesLocal, it extends several remote proxies.
K, r
On 8/3/20 4:21 AM, Marcel Taeumel wrote:
Hi all!
I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-)
Best, Marcel
Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev [squeak-dev@lists.squeakfoundation.org](mailto:squeak-dev@lists.squeakfoundation.org):
Hello, there,
In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification:
Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved.
The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:.
K, r
NB: here is a chained message sending eventually, with Promises.
((10 eventual factorial / 100) * 25) whenResolved: [:i | i value].
On 8/2/20 8:55 AM, Robert Withers wrote:
Hi all'y'all!
Here is a textbook on Promises, for your understanding.
[Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.]
http://dist-prog-book.com/chapter/2/futures.html K, r
On 8/1/20 12:09 PM, Robert Withers wrote:
Good afternoon!
I wish to offer a proposal for discussion to include PromisesLocal into trunk and to replace the implementation of Promise/BrokenPromise with PromiseERefs and BrokenERefs. The underlying concurrency model has explicit use of an event loop in PromisesLocal. The code size is minimal but adds the Promises/A+ specification to Squeak, that can be extended into a remote reference solution and an Agent communications architecture. Exceptions are processed.
I want to define a VatSemaphore that allows the user to #wait/#signal, and they get 'immediate' control flow which most folks find as a valid way to describe steps taken.Under the covers the VatSemaphore is connected to the Vat, as an element in a forthcoming continuationPool. So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the continuation is captured and placed in the pool and the vat's event loop continues with the next event. When #signal is sent to this VatSemaphore, the continuation is scheduled: in the queue and removed from the pool. The event loop will process the continuation.
On 7/28/20 3:41 PM, Jakob Reschke wrote: My other suspicion is that we would nevertheless need an extended debugger to deal well with such eventual control flow. A debugger with a "step to resolution" or so that steps to the point where the messages are eventually answered, or the receiver even activated.
I think that this is a great idea!
Research in this direction would be AWESOME!
On 8/1/20 11:39 AM, Robert Withers wrote:
On 7/28/20 3:41 PM, Jakob Reschke wrote: Current Kernel Promises are also not good at that without sprinkling breakpoints... This and the dreadful error handling ("well so I forgot the block argument for the callback again and got an error from value:, now how do I find out in the debugger which method even contains my wrong block?!?"
What if the debugger could allow you to browse reactor creation methods? Where is the closure created?
I can imagine an implementation of EIO ( http://wiki.erights.org/wiki/EIO_Redesign ), Eventual I/O, that has a #whenAvailable: semantic. Then the UI event loop is just an EInputStream and we could flip the entire system over to using a promise architecture.
Kindly, rabbit