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: Tue, 3 Apr 2018 10:31:52 +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-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51312 Date: 2018-04-03T10:31:52+02:00 List-Id: On 03/04/2018 00:13, Robert I. Eachus wrote: > On 3/28/2018 11:02 AM, 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. >> >> Needless to say that I don't find closures any appealing. > > My brain hurts.  It is possible to generate symmetric co-routines in > Ada.  But you keep falling off the wagon since non-symmetric co-routines > and especially non-blocking routines are SO much simpler.  The idea here > is apparently to create a write "thing" that abstracts the timing > characteristics of the physical devices involved in the writing away. > Start with a library package that creates a hidden task type: > > with Ada.Finalization; > generic >   type Object is private; >   type File is new Ada.Finalization.Limited_Controlled with >     Name: ...--parameters for creating the output target. >   end record; > package Asynch_Writes is >   procedure Create(...); >   procedure Write(Obj: Object); >   procedure Close; > end Asynch_Writes; > > Strange, this looks a lot like the interface to Text_IO. ;-) Yes, the idea is to have same interfaces. > The File > has a controlled part to insure that when the File object goes away, the > File instance does too, and attempts to call Write raise an exception. > (Close should do nothing if the File is already closed. ;-)  File type > is limited to insure that copies are not made. > > What does a blocking package look like?  Much the same, except for the > name.  You don't need to create a task in the body with an entry Write, > but that is implementation detail. ;-)  If you want, you can replace the > task with a protected object to get co-routine semantics. My brain hurts too. I don't understand how this is not blocking. When Write is called it does not return until I/O is complete. Protected object or not, the caller is stuck there. Co-routines are supposed to steal the caller's task and pass it to another thread of control while awaiting for Write to complete. It is just tasking without time sharing and scheduling. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de