Re: Ada-Oriented GUI

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-03-28 20:07, Alejandro R. Mosteo wrote:
> 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).

If this is only data, then it is just standard OO approach:

    type IO_Request is abstract ...
    procedure Complete_Write (Request : in out IO_Request) is abstract;

    procedure Start_Write
              (  File : in out File_Type;
                 Request : in out IO_Request'Class
              );

You derive from IO_Request, override Complete_Write, queue it using 
Start_Write.

The problem is that the program logic is split between bodies, which 
makes this method so uncomfortable.

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

Yes, this is what I meant.

> 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;

Replacing ";" with "&"? (:-)) The real horrors start with conditional 
choices, loops, passing results from earlier steps down the chain, 
handling exceptions, honoring time constraints etc, everything we can 
keep simple and elegant in the "blocking" approach.

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

It not much the closures, but the programming style which forces program 
logic inversion. The things of primary reader's interest happen in 
bodies you pass as parameters or as primitive operations of parameters 
(in OO case). This is just a bad model. In that aspect it is no 
different from traditional callbacks.

OO decomposition wraps these callbacks into primitive operations.

"Functional" decomposition wraps callbacks into closures.

In both case the mess stays.

Choosing between these two I clearly in favor of OO, because it 
encapsulates the state into the object while the closure does it in some 
implicit way. Using plain access-to-subprogram instead of closure is the 
worst approach because maintaining the state is left to the programmer, 
which ends up with ugly void * User_Data passed around to be cast from 
type to type at run-time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de