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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200802/0315a341/attachment.html>