From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Wed, 28 Mar 2018 20:07:31 +0200 Organization: A noiseless patient Spider Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 28 Mar 2018 18:07:31 -0000 (UTC) Injection-Info: h2725194.stratoserver.net; posting-host="460fb46a4c0350d70ba2f75d850e57e2"; logging-data="16502"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Y4ohDORtoiDVBa9X/Y5XY" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:HNFllrXEO7MXU0DNIyFOx1g+6rw= Xref: reader02.eternal-september.org comp.lang.ada:51240 Date: 2018-03-28T20:07:31+02:00 List-Id: 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...