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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Sun, 26 Jun 2016 08:26:40 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> <3a978db3-e775-4e4a-acc0-8082f7376069@googlegroups.com> NNTP-Posting-Host: w/2xSGckQeJEFvqsQFNodA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30941 Date: 2016-06-26T08:26:40+02:00 List-Id: On 2016-06-26 04:02, rieachus@comcast.net wrote: > On Saturday, June 25, 2016 at 3:11:57 AM UTC-4, Dmitry A. Kazakov wrote: > >> The problem at hand is that parallel asynchronous code cannot be >> designed in a reasonable way, at all. It is written it in a form of a >> state machine, logically and technically *gotos*. It is the state of >> software engineering of 70s wrapped in Ada constructs. > > Um, I've always thought it funny that Ada state machines and Ada > tasking mix nicely, and both need to be at the library level to work > efficiently. I always used LALR on Multics which could handle LALR(k) > grammars for any k, and even some non-LR grammars. But it could also > take a source file which mixed PL/I, C, Fortran, or Ada code with the > grammar productions, and generate a (huge) source file which used a > table driven engine. > > If, and I understand it is a big if you could map the input to one > or more independent sequential file, everything was wonderful. However if > you wanted to handle interacting inputs you were up a creek. This > limitation is not as bad as it sounds. To take am aircraft radio, there > would be several subsystems that could be handled separately. The > interrupt causing events (from operator input) could be mixed into the > data stream: operating_state ::= (receiver_input) | (transmission) > |(interrupt) (operating_state); > > I can't imagine building a complex real-time system without a > grammar tool and Lui Sha & Goodenough real-time scheduling support tools. In my opinion formal grammars is one of the most useless CS invention, but that is beside the point. Which is yes, it would be interesting to try co-routines for writing parsers. It may work or not. From the software design POV it is a choice what is to be handled as a set of callbacks vs. as a control flow sequence. Co-routine is a method to convert callback into a sequence. It is not always useful and not always possible. If callbacks are short and independent, there is little volatile state to share and keep between callback they better remain callbacks. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de