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,FREEMAIL_FROM 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!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Victor Porton Newsgroups: comp.lang.ada Subject: Re: Generators/coroutines in future Ada? Date: Mon, 10 Jul 2017 02:56:38 +0300 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: UZPBofpaGWLolaA02L4QDw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@aioe.org User-Agent: KNode/4.14.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47335 Date: 2017-07-10T02:56:38+03:00 List-Id: Dennis Lee Bieber wrote: > On Sun, 09 Jul 2017 23:19:23 +0300, Victor Porton > declaimed the following: > >>Is it possible to implement generators and coroutines (like as in Python) >>in a future version of Ada? >> >>I am not an expert on how generators are implemented. Is it possible in a >>language like Ada? >> > > Generators -- not as you think of them (ad hoc, on-demand, creation). > cf: > http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-5-2.html > (which is focused on random number generation, but basically anything > could follow the schema). You'd have to define a (generic) package with a > generator type definition, and methods to manipulate state of the > generator. The instances of the generator type are what holds the state > between invocations. What you described is a workaround how to code equivalently to generators in absence of true language support of generators. It is just like object oriented programming in C. >>Well, I think it could add additional reliability, because programming of >>processing of different "streams" becomes easier and thus less error >>prone. > > I wouldn't hold out much hope for coroutines. Ada was created from the > start with the concept of independent tasking (all the way back before > 1980!). Formal co-routines (a la Modula-2) do not fit the philosophy as > they are a cooperative "task" switch (in classic co-routines, each routine > determines when it will transfer control to another, and possibly where in > that other transfer goes to -- it was even doable in FORTRAN-IV when > statement labels could be passed in/out of a call). I've never studied the > Python "co-routine" but it does not map to what I consider a co-routine. -- Victor Porton - http://portonvictor.org