Re: [TCLCORE] Question on coroutines

[Kevin K. <kev...@gm...>]

miguel sofer wrote: [quoting
http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf]:

> <cite>
> The basic characteristic of symmetric coroutine facilities is the 
> provision of a single control-transfer operation that allows coroutines 
> to pass control explicitly among themselves. Marlin [1980] and Pauli and 
> Soffa [1980] argued that symmetric and asymmetric coroutines have no 
> equivalent power and that general coroutine facilities should provide 
> both constructs. However, it is easy to demonstrate that we can provide 
> any of these mechanisms using the other; therefore, no expressive power 
> is lost if only asymmetric coroutines are provided in a language.
>     The implementation of symmetric coroutines on top of asymmetric 
> facilities is straightforward. Symmetrical transfers of control between 
> asymmetric coroutines can be easily simulated with pairs of yield–resume 
> operations and an auxiliary dispatching loop that acts as an 
> intermediary in the switch of control between the two coroutines. When a 
> coroutine wishes to transfer control, it yields to the dispatching loop, 
> which in turn resumes the coroutine that must be reactivated.
> </cite>

At first, I found Miguel's terse explanation to be understandable
only at a "my brain hurts!" level.  Once I understood it, it looks
to be a cheap and elegant way to implement full-symmetric coroutines
without a dispatcher in the main routine.

The question that remains is whether this functionality is what we
want. As the Lua paper mentions, symmetric and asymmetric coroutines
are equivalent. (I believe that I read the Pauli and Soffa paper at
the time, and wondered why they asserted that they were not.) Since
[yieldto] is obviously a difficult concept to explain - a couple of
very smart people here were puzzled at first - the fact that comparable
functionality is easily done with existing facilities would seem to
argue against including it.

That said, the trick of having [yieldto] work by substituting the
call to the coroutine with another call is clever. And the fact that
the other call might be any other command, not just another coroutine,
might prove to be useful. (I can't imagine *how*, just at the moment,
but that's most likely a limitation of my imagination.) So I'm certainly
fine with experimenting with this in 'unsupported' and letting the
imaginative people see what they can make of it.

-- 
73 de ke9tv/2, Kevin