[gpderetta]

So, don't you agree that the stackful equivalent of your stackless example will use something like 'go g(v1)' which will only capture v1?

Without explicitly forking v2 will be captured, but then it is a completely different program with different semantics and it doesn't make sense to say that it captures more.

Edit to be more practical: in c++ you can have both stackless and stackful coroutines. If you write the same program, say using asio, with either feature, the same data will be captured.

[naasking]

> So, don't you agree that the stackful equivalent of your stackless example will use something like 'go g(v1)' which will only capture v1?

It will only capture v1 and also reserve a larger stack space in case the new computation needs it, where the stackless equivalent does not require this.

> Without explicitly forking v2 will be captured, but then it is a completely different program with different semantics and it doesn't make sense to say that it captures more

It doesn't have different semantics just because v1 changes ones space behaviour and not the other's.

I'm not interested in Turing tarpit arguments that one can be made equivalent to the other. As I've already said, the point is what existing systems encourage what sort of program architectures and what allocation behaviour naturally follows. It's long been evident that stackless abstractions clearly must capture strictly less state at any given time.

[gpderetta]

If you are not interested in discussing it further so be it. But go did have segmented stacks that didn't require reserving additional space.

[naasking]

Go's segmented stacks are 2kB and used to be more. That is "reserving additional space".

Stackless space allocation is on the order of single or double digit bytes by contrast. There is no reasonable way to conclude they are comparable.