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
X-Received: by 10.99.101.68 with SMTP id z65mr1650884pgb.102.1499849878563;
        Wed, 12 Jul 2017 01:57:58 -0700 (PDT)
X-Received: by 10.36.104.205 with SMTP id v196mr836452itb.3.1499849878518;
 Wed, 12 Jul 2017 01:57:58 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!v202no163737itb.0!news-out.google.com!f200ni529itc.0!nntp.google.com!v202no163736itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 12 Jul 2017 01:57:58 -0700 (PDT)
In-Reply-To: <ok26bp$lt4$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=165.225.16.231;
 posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
NNTP-Posting-Host: 165.225.16.231
References: <oju353$b75$1@gioia.aioe.org> <ok001a$rhm$1@gioia.aioe.org>
 <ok26bp$lt4$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f573b3ad-db2d-42f5-9b53-cfed4b877519@googlegroups.com>
Subject: Re: Generators/coroutines in future Ada?
From: Maciej Sobczak <see.my.homepage@gmail.com>
Injection-Date: Wed, 12 Jul 2017 08:57:58 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:47376
Date: 2017-07-12T01:57:58-07:00
List-Id: <comp.lang.ada>

> Taking the example from Wikipedia:
>=20
> function startAt(x)
>    function incrementBy(y)
>        return x + y
>    return incrementBy
>=20
> variable closure1 =3D startAt(1)
> variable closure2 =3D startAt(5)

Note that this example does not exploit (pun intended) the fact that such v=
ariables can be created dynamically, where their exact number is not known =
until the program is run. Imagine an array (of length determined at run-tim=
e) of such generators. This shows that static approach of Ada is not always=
 convenient and is not applicable to every problem.

Dmitry is right that generators can be replaced with functions that operate=
 on explicit state, but generators are useful, because they have the same i=
nterface as stateless functions[*] and can be used as arguments in higher-l=
evel generics that accept "callable" entities without caring about whether =
they are stateful or not[**]. Functional languages (or at least those that =
claim to have some features from functional programming) are convenient for=
 gluing stuff together this way, with obvious compromises in other areas.

[*] That is, there is some commonality between stateless and stateful funct=
ions and it might be useful to capture this commonality in some programming=
 concept that is not present in Ada.

[**] C++ relies on such constructs in the STL library (and many others), bu=
t calls them "functors" instead. That is, a generator can be implemented as=
 a stateful functor (and they can be created dynamically). Whether they are=
 used wisely is another story.

--=20
Maciej Sobczak * http://www.inspirel.com