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" <alejandro@mosteo.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada-Oriented GUI
Date: Thu, 22 Mar 2018 18:29:40 +0100
Organization: A noiseless patient Spider
Message-ID: <p90p64$d9s$1@dont-email.me>
References: <p8lpr4$bgl$1@dont-email.me> <p8t4t6$1j4v$1@gioia.aioe.org>
 <ea8acda4-bb00-43f5-b826-170bd8e0c2c9@googlegroups.com>
 <p8u168$1ag6$1@gioia.aioe.org>
 <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com>
 <p8u5j3$1ise$1@gioia.aioe.org>
 <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com>
 <lytvt9fdm8.fsf@pushface.org>
 <858fbe8b-43a2-4ee3-ad51-1d100123a1a3@googlegroups.com>
 <p8ue9i$252$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 22 Mar 2018 17:29:40 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="7293d138f01b9451d9fc048d81af480d";
	logging-data="13628"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1991iDl+WA6y2f9IRbjt2hE"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
In-Reply-To: <p8ue9i$252$1@gioia.aioe.org>
Content-Language: en-US
Cancel-Lock: sha1:+61dT8ZqffWGf0LnB14vQBJrIMQ=
Xref: reader02.eternal-september.org comp.lang.ada:51138
Date: 2018-03-22T18:29:40+01:00
List-Id: <comp.lang.ada>

On 21/03/18 21:11, Dmitry A. Kazakov wrote:
> On 2018-03-21 20:51, Dan'l Miller wrote:
>> On Wednesday, March 21, 2018 at 2:11:13 PM UTC-5, Simon Wright wrote:
>>> I suspect that Dmitry only meant that output-pending must occur before
>>> output-complete, whichever thread you view it from.
>>
>> I assume that output here is event emission from the head-end of the 
>> river from the upstream perspective of producing output to downstream 
>> receivers that handle that output-from-upstream as input. 
> 
> This is not how asynchronous I/O works in many cases. The I/O request is 
> queued in one thread, initiated in another, processed in third, 
> completed in fourth.

I'm not sure I'm understanding the gist of this point of the 
conversation, but exactly that kind of thread-hopping is trivial to 
write in Rx.

> Your approach seem to impose some heavy constraint not just on GUI as 
> many existing frameworks do, which people really hate, but on all 
> system. Good luck with that, but don't expect everybody to embrace that
Rx certainly imposes a way of thinking, most like using a functional 
language does. It's not an all-or-nothing thing though, there is a 
well-defined entry and exit point. Also, there's something pleasurable 
about it, is like connecting dots to make a picture, or matching puzzle 
pieces.