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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Mon, 23 Jun 2014 22:14:13 +0200 Organization: cbb software GmbH Message-ID: References: <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> <5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net> <18et97c0c22vc$.y98lxxfblijn.dlg@40tude.net> <08f83f70-ccb1-45ec-8a4c-46e3442745b8@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: qHNcUCBwwd01dPSBp/L1cg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:20564 Date: 2014-06-23T22:14:13+02:00 List-Id: On Mon, 23 Jun 2014 12:21:11 -0700 (PDT), Dan'l Miller wrote: > On Monday, June 23, 2014 12:14:24 PM UTC-5, Dmitry A. Kazakov wrote: >> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote: >>> "Dmitry A. Kazakov" writes: >>>> Programming a state machine is turning all design upside down. If >>>> there were user-defined task support one could program this as if it >>>> were in proper tasks. >> >>> I find it easier to think about state machines as state machines rather >>> than by encoding them using the program counter! I geuss it depends on >>> your starting point. > > In the spirit of lambasting the lack of direct representation of > finite-state machines (FSMs) in Ada: Egh? Ada lacks nothing for programming FSM. It has: 1. gotos and labels 2. access to subprogram type 3. dispatching Ada has enumeration types so that states could be named. Ada has the case statement checking all alternatives. Ada has ranges in case statement in order to specify subsets of states and subtypes to name such subsets. Thus either possible way of implementing FSM is fully, totally, and exhaustively supported in Ada. >> As an example consider reading from a stream without blocking. When there >> is no more data available you switch to another co-routine (reading another >> stream). This is programmed as if reading from the stream was blocking. The >> co-routine is continued when more data become available. On top of these >> stream could be a mountain of protocols or a whole Ada compiler taking the >> stream as a source. Doing this as a state machine, upside-down driven by >> incoming characters would be extremely tedious. >> >> The idea of user-defined tasking is that the user would also provide the >> pool to allocate the task stack and would activate/deactivate his tasks. > > In the spirit of humbly learning something new and appreciating any > potential beauty: > > Dmitry, do you advocate the use of "co-routines" (as Ada tasks, if I > understand you correctly) for the modeling of arbitrarily-complex > finite-state machines (FSMs)? If so (and if it scales), perhaps you can > explain the design idiom more completely so that it handles FSMs of > arbitrary complexity. The idiom is: unless at gunpoint, never ever use FSM. > It seems that your usage here of "co-routines" to represent FSMs No, I don't want to represent state machine. I want to get rid of it completely. More generally, I don't want a data-driven architecture. FSA as a programming pattern, is an instance of data-driven architecture. > somewhat > resembles C.A.R. Hoare's monitors, but perhaps I am taking your > "co-routines" in a different direction than you intend. I intent to reuse normal Ada code that deploys I/O (like file I/O, socket I/O etc, which is 99.999%, for the rest 0.001% cases where asynchronous non-blocking I/O is used. It does not work now because blocking I/O requires a task to await for data it expect. That is, the I/O is blocking. With asynchronous I/O, usually from many channels simultaneously, you don't have a task to block, you are forced to deploy a set state of machines activated each time data gets available on some I/O channel. You select the machine servicing the channel, feed the machine with data, perform transitions until there is no more data, store the machine state, look for another channel etc. Now consider what this becomes when you have to output also asynchronously! as you perform transitions. This is the case for HTTP and other network protocol servers. Where with normal I/O you have: loop read input process write output end loop; here you'd have an utter mess. It is a disgusting software pattern extremely low-level and difficult to use, absolutely unmaintainable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de