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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Thu, 29 Mar 2018 09:58:57 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 X-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51249 Date: 2018-03-29T09:58:57+02:00 List-Id: 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