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 X-Received: by 10.182.125.4 with SMTP id mm4mr448722obb.49.1403551272078; Mon, 23 Jun 2014 12:21:12 -0700 (PDT) X-Received: by 10.182.216.226 with SMTP id ot2mr22409obc.31.1403551271901; Mon, 23 Jun 2014 12:21:11 -0700 (PDT) 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!news.glorb.com!hn18no7438604igb.0!news-out.google.com!gf2ni11igb.0!nntp.google.com!hn18no7438599igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 23 Jun 2014 12:21:11 -0700 (PDT) In-Reply-To: <18et97c0c22vc$.y98lxxfblijn.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org> <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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <08f83f70-ccb1-45ec-8a4c-46e3442745b8@googlegroups.com> Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! From: "Dan'l Miller" Injection-Date: Mon, 23 Jun 2014 19:21:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:20562 Date: 2014-06-23T12:21:11-07:00 List-Id: 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. >=20 > > 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-sta= te machines (FSMs) in Ada: A programmer should not need to go through mental gymnastics to represent= a crystal-clear analysis construct (e.g., an FSM) in some sort of contorti= on just because someone in 1978 omitted it from an excessively-sequential i= mperative programming language because excessively-sequential imperative pr= ogramming languages encouraging vast call-trees of subroutines per thread o= f execution were in vogue during the 1970s and adjacent decades. Perhaps Ada202X can do something more than mere dotting of "i"s and crossin= g of "t"s so as to provide a direct intuitive representation of FSMs within= Ada (assuming that Ada does not already have such an intuitive design idio= m for FSMs, as potentially explored below). Direct intuitive representatio= n of FSMs would be highly useful in Ada's historically-most-frequent deploy= ments: embedded realtime systems interacting with hardware. The Ada202X c= ompiler could mathematically-prove some aspects of sanity of the FSM, givin= g compile-time errors for certain categories of glaring design errors in th= e FSM a la the numerous other compile-time assurances for safety-critical s= ystems that are already part of Ada. (Plus it would give Ada a special sau= ce that very few other compiled languages have in either its core language = or in its standard library, Erlang & C++'s Boost notwithstanding. Btw, Ada= does need a few more claims to fame to be competitive with the other curre= nt programming-language darlings that get asked to dance on the dance-floor= more often than Ms. Ada does. Direct intuitive representation of FSMs wit= h compile-time error-checking [as a directed graph in graph-theory] could b= e one of those claims to fame.) > As an example consider reading from a stream without blocking. When there > is no more data available you switch to another co-routine (reading anoth= er > stream). This is programmed as if reading from the stream was blocking. T= he > 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 th= e > stream as a source. Doing this as a state machine, upside-down driven by > incoming characters would be extremely tedious. >=20 > 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 potenti= al beauty: Dmitry, do you advocate the use of "co-routines" (as Ada tasks, if I unde= rstand you correctly) for the modeling of arbitrarily-complex finite-state = machines (FSMs)? If so (and if it scales), perhaps you can explain the des= ign idiom more completely so that it handles FSMs of arbitrary complexity. = Or perhaps you can provide a URL to an academic paper that describes repre= senting FSMs of arbitrary complexity via "co-routines". It seems that your usage here of "co-routines" to represent FSMs somewhat r= esembles C.A.R. Hoare's monitors, but perhaps I am taking your "co-routines= " in a different direction than you intend. If resembling Hoare's monitors= (or POSIX's condition variables) [and assuming that each Ada task in the s= et of co-routines takes on the role of each state in an FSM], how does this= idiom scale well in so far as not having immensely-complex conditional-bra= nching tests for representing each task's/state's traversal of a link/edge = in arbitrarily-complex FSMs.