Re: Ada-Oriented GUI

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

On 28/03/18 17:02, Dmitry A. Kazakov wrote:
> On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
>> On 24/03/18 14:12, Dmitry A. Kazakov wrote:
> 
>>> Now, programming this is like scratching your left ear with the right 
>>> hand. I keep on asking for co-routines in Ada to break out of this 
>>> lousy awful mess. To rein assorted mess of events/callbacks into a 
>>> sequence imperative calls to be a able to program it as if it were an 
>>> uninterrupted thread of control maintaining its state, just like if 
>>> the I/O were synchronous.
>>
>> I've never used coroutines. Since this kind of "imperative-like" 
>> sequences is what Rx provides, I understand that coroutines will allow 
>> the same without staying in the declarative realm?
> 
> I think so. Let you have Start_Write call and Write_Complete callback. 
> The idea is to be able to write code in a "blocking" manner like:
> 
>     declare
>        State : ...; -- Data local to the co-routine
>     begin
>        Start_Write (...);
>        Wait_For_Complete (...); -- Give up the thread of control until
>        ...                      -- Write_Complete
>        Start_Write (...);
>        ...
> 
> My understanding is that the "functional" style with closures is an 
> alternative to this which calls Start_Write and then queues a closure to 
> be called on Write_Complete. The closure will carry State with it and 
> perform chained actions.

I think your understanding is right. Talking Rx, the data being processed 
should ideally be the state. Actions need not be technically closures, 
since they receive and return the data to pass along (I might be 
imprecise here about closures; this is a problem of having studied CS in 
another [human] language).

You can have actual closures too, and lambdas in recent Java. In my Ada 
implementation subprograms cannot be closures since they have to be at 
library level (I guess those and instantiations can be considered 
closures on the library level, I fear I'm mixing theoretical and 
implementation concepts here. I'm referring as a closure to a subprogram 
that accesses the enclosing subprogram scope.)

A similar example in RxAda would be:

procedure Write (Item : in Item_Type) is ...
    -- Take as much time as needed to write the Item
end Write;

declare
    S : Subscription :=
      Generator_Of_Items &      -- May generate them at any pace
      --  Pre-write actions would go here
      On_Next (Write'Access) &  -- Write as they come
      --  Post-write-actions would come here
      Subscribe;
begin
    null; -- Nothing to do here
end;

Or you can:

declare
    S : Subscription :=
      Generator_Of_Items &         -- May generate them at any pace
      Subscribe_On (Background) &  -- Ensures Generator goes to BG
      Map (Process'Access) &       -- Preprocess/transform items
      Observe_On (Writer_Pool) &   -- Use a pool of dedicated tasks
      On_Next (Write'Access) &     -- Writes one item
      Subscribe;
begin
    null; -- Proceed with other things
end;

> Needless to say that I don't find closures any appealing.

I seem to remember your objections from other threads, but I don't 
remember why exactly (I found them very cumbersome for the standard 
containers before the latest syntax sugar).

>> There are AIs for generators in Ada, maybe these will be among the 
>> chosen ones?
> 
> AFAIK, this is not what is required in order to support the above. A 
> co-routine needs a local stack not bound to any task and a method to 
> convert blocking calls into "save state, give up, wait for a 
> callback/event".
> 
> P.S. Maybe all this would become irrelevant for processors with thousands 
> of cores. Then we would be able to run anything in a blocking manner 
> without context switching penalty. I think that memory bottleneck would 
> likely kill such architectures, but who knows...