Robert wrote:I have not had the time (and there are probably other reasons) to follow this discussion carefully, so I apologise if my remarks seem rather trivial.
Some time ago I had an algorithmic problem (a bit similar to the same frimge question) and found, on the internet, a solution described in terms of Python Iterators with Yields (if I remember correctly). I thought: "That's neat, but I can't see how to do that in Component Pascal". But it was apparent that a prettly simple understanding of a couple of language (Python) keywords gave access to a significant capability; the whole thing was not too scary.
This discussion is really quite scary for a potential very infrequent user of coroutines - I've only actively wanted them once in a lifetime! The Co package is 2 MByte (compressed); that alone makes one feel that it is aimed at the expert user who can cope with (and needs) very many specialised options.
Are we going in the direction of having two (or three if we think of Ivan's suggestions as an alternative) overlapping packages in both CPC & the Center distribution? That, I think, would make the subject even more inacessible for the new or casual user.
Is there a balance to be struck between the needs of the expert and the wishes of the beginner? Are we heading towards it? Or is such a compromise the worst of all worlds, and we should choose a target audience (experts, I guess) and pitch the development to their needs?
And what about the overlap between the 2014 Co_ subsystem and the 2017 Center proposals? Is it large overlap? Is it a good thing? Is it a bad thing?
The center's Coroutines module is designed in such a way that it serves both, experts and beginners.
Actually, there is not much difference between experts and beginners in this case.
The difference in the design of a coroutine package is more if it aims to be a
general purpose tool
or a
special purpose tool. The center's Coroutines are general purpose while the Co_ package,
as far as I understand it, is a special purpose tool. It aims specifically at data flow programming,
or however that may be called. This is a very narrow focus far from being general purpose.
It is easy to construct perfectly meaningful applications that cannot be implemented with Co_.
Nevertheless, some people may find it useful if their application fits with the supported pattern(s).
Robert, if you want to get started with coroutines, I would recommend to start with a plain Coroutines.Coroutine
example. Here you see the basic mechanism without any bells and whistles. ObxCoroutines contains
such an example. The next step would be to look at the Iterator example (SameFringe) and then look
at the Task example (Primes) or vice verse. Compare the Primes example with the similar example in ObxActions.
- Josef