Re: Ada-Oriented GUI

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov wrote:
> So it is inconsistent unless packed into single thread. No difference, 
> exiting GUI do just same.

  Yes, it is customary (or required in most OSes/frameworks) for all UI processing to be in the same single thread.  Even in Microsoft Windows' various API/personality flavors, it is required for all UI processing within the same window to be performed in the same single thread.  From my reading of Jeffrey Carter's description of his work, he was continuing this precedent of all UI processing in a single thread, simply moving it off from the main thread to some other single thread.

> > Conversely, there is no order to preserve between different single-threaded senders.
> 
> Surely there is.

  Surely in the progress of time in reality, there is not.  This asynchrony is the basis of realtime systems.

> The order is application level semantics.

  Then the application is maldesigned, not conforming to the asynchrony of the various autonomous timelines in reality.

> (This is a general problem of event-driven architectures. They are 
> non-scalable, non-composable, unstructured and unmaintainable when 
> become large).

  Rx is clearly chipping away at that increasingly obsolescent state of affairs.  Please read the books.

> > E.g., async filesystem I/O events can interleave GUI human-activity events can interleave application-lifecycle events can interleave network packet-arrival events arbitrarily and differently each execution.
> 
> I don't see how this is related to GUI design issues,

It is unrelated to designing a GUI per se at Microsoft or at Apple or at Google.  It is highly related to designing an •application• that is built atop that GUI infrastructure.

> except that when 
> file system I/O indirectly cause GUI events. Then ordering of the events 
> (output-pending, output-complete) must evidently be preserved when used 
> in a progress indicator.

So you don't see that all permutations of unavoidable race conditions in disparate topics (that naturally occur in reality before a software design ever existed) need to be sanely handled a posteriori in a nonpanicky methodical disciplined-structure way.  Apparently, you think that all race conditions from every nook & cranny of every corner of reality can somehow be defined away a priori by some sort of superdooper clever design.  Well, more power to you then, because you can show all those Rx folks where their entire worldview is horribly wrong from the git-go.  We look forward to seeing that superdooper clever a priori design that shows all the aficionados of a posteriori where they went awry.