[Proposed] include PromisesLocal in trunk

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

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.]

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

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].

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

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

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 [hidden email]:

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

Thank you, Marcel! Great feedback, I will look to it.

K, r

On 8/3/20 10:48 AM, Marcel Taeumel wrote:

Hi, Rob.

> Why are you -1 with PromisesLocal?

- Missing class comments, thus no clarification of vocabulary "ERef", "Vat", "Reactor", "Resolver", etc.

- Too many extensions in Object and ProtoObject

- Some unconventional wording/style such as #newWithNick:, #onOneArgClosure:..., 

This is just very high-level feedback and not specific to your implementation strategy. I did not have more time yet to take a closer look, sorry.

Best,

Marcel

Am 03.08.2020 12:55:18 schrieb Robert Withers [hidden email]:

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 [hidden email]:

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