issue-#156 adding Coroutines to BlackBox

[Josef Templ]

DevLinker.WriteHeader contains the following statements:

Thanks for the info.

This means 65KB committed and 2MB reserved.

- Josef

[Josef Templ]

I have added the classical SameFringe example to ObxCoroutines.

diffs at https://redmine.blackboxframework.org/p ... 3634663ac9

- Josef

[Robert]

I have added the classical SameFringe example to ObxCoroutines.

Should the Obx map be updated?
Should the Obx menu be updated?
Would the Obx menu be better with sub-menus?
Do these questions also apply to other new Obx modules?

Some time ago I read about Python iterators and the "Yield" statement when trying to solve a problem of this type - I forget the details.
Is the Python "Yield" similar to the BlackBox "Transfer"?

[Josef Templ]

I have added the classical SameFringe example to ObxCoroutines.

Should the Obx map be updated?
Should the Obx menu be updated?
Would the Obx menu be better with sub-menus?
Do these questions also apply to other new Obx modules?

Some time ago I read about Python iterators and the "Yield" statement when trying to solve a problem of this type - I forget the details.
Is the Python "Yield" similar to the BlackBox "Transfer"?

The Obx map is already extended.

For the coroutines examples no Obx menu entry is needed.

Restructuring the Obx menu into hierarchical menus would be a good idea
but outside this issue, I think.

The term "Yield" is typically used for returning a new value from an iterator,
which is an example for using coroutines. Such iterators are essentially a "programming pattern".
Since this is a very common pattern some languages introduce special syntax for it.
So Yield is typically being used together with a value, such as "Yield next" and the
meaning is to transfer control to the caller and to return a value that can be used
at the caller's site, which also needs some special syntax there.
CP has no special syntax for that but with the current Coroutines design it is easy to
achieve the same effect by introducing a "next" record field in the coroutine object
as can be seen in the Iterator example.
This pattern, BTW, shows the advantage of introducing coroutines as objects
and not as plain procedures as it was the case in Modula-2.
Python has changed its coroutine support several times as far as I have read.
I don't know the details though. There is also coroutine support planned for
C++ 17 with a lot of special syntax.

- Josef

[Ivan Denisov]

Dmitry Dagaev commented this issue in Russain board:

1. You need to specify that Coroutines is already added in 2014, but without the support from Kernel.
2. You need to make Kernel support available for all packages. Equal opportunities.

https://forum.oberoncore.ru/viewtopic.p ... 19#p100726
https://forum.oberoncore.ru/viewtopic.p ... 47#p100746

[Josef Templ]

Dmitry Dagaev commented this issue in Russain board:

1. You need to specify that Coroutines is already added in 2014, but without the support from Kernel.
2. You need to make Kernel support available for all packages. Equal opportunities.

https://forum.oberoncore.ru/viewtopic.p ... 19#p100726
https://forum.oberoncore.ru/viewtopic.p ... 47#p100746

The package (Co_) is already mentioned in the issue description.
I have added the date to it now. I didn't expect that the date is important
for anybody but it is not a problem to add it.

Kernel support for coroutines is available for all packages.
I would expect that it is possible to adapt the Co_ package to using
the Kernel coroutine services just like module Coroutines does it.
If it is not possible we can look at it.

- Josef

[Ivan Denisov]

I think, that we should discuss this feature in the community board first. Dmitry will have ability to participate in the discussion.

What if we keep this issue for BlackBox 1.8 ?

[Robert]

What if we keep this issue for BlackBox 1.8 ?

I hope not. It looks like a very interesting proposal I am keen to have available (in a stable release) quickly; even if the initial proposal does ultimately prove to be a bit immature.

[Ivan Denisov]

What if we keep this issue for BlackBox 1.8 ?

I hope not. It looks like a very interesting proposal I am keen to have available (in a stable release) quickly; even if the initial proposal does ultimately prove to be a bit immature.

So, if add to 1.7.1 we all should be ready to change the realization and interface in 1.8 after sufficient discussion...

I see that Dmitry also is ready to support the discussion:
https://community.blackboxframework.org ... t=164#p940

[Ivan Denisov]

Dmitry said that first realisation for Kernel without WinApi calls providing more "Equal opportunities".
https://forum.oberoncore.ru/viewtopic.p ... 57#p100757

What I see is a list of StackInfo structures for local coroutine stacks, the functions of working with them, InitStacks, AddStackInfo, SetStackBase, RemoveStackInfo, SwitchStackInfo, and the modification of MarkLocals - it suits me.

However I am not happy with WinApi in Coroutines module, because this module should provide only interface and platform independent logic...

I have to return to my experiments soon with transformation of initial Josef's proposal to find some compromise solution.