Re: [TCLCORE] Question on coroutines

[Neil M. <Nei...@no...>]

On 7 Dec 2009, at 14:44, Kevin Kenny wrote:
> Neil Madden wrote:
>> Or perhaps "yield [list foo bar]" and have the caller do "eval [$coro]"? Isn't that exactly what yieldTo does, but hiding the [eval], or am I still missing something?
> 
> You're not missing much. It's a minor simplification; if the coro were
> always invoked with [eval [$coro]], then [yield] would behave the same
> as [yieldto] without it.  In that case, though, if the coro is actually
> ready to return a value, it would have to execute something like
> [yield [list return -level 0 $value]].  And the tangle gets more
> complicated, because the dispatcher isn't a simple [eval [$coro]];
> it has to continue evaluating a whole chain of control transfers
> (and still be able to escape with [return -level 0] or whatever at
> the end).
> 
> Equivalent power, different notation.

OK, I sort-of see now. Wrapping all the coroutine yields in an [eval] is easily accomplished:

 proc coro {name args} {
    coroutine $name.coro {*}$args
    interp alias {} $name {} dispatch $name.coro
 }
 proc dispatch {coro arg} { eval [$coro $arg] }

To yield a value, you can just do (as you say):

 proc value val { list return -level 0 $val }
 yield [value $foo]

I'm not sure I see in what case the dispatcher needs to do more than a simple [eval], though. In what situation do you get a chain of control transfers with yieldTo? (My understanding is that this behaves like [tailcall], so there should be no chains).

Not that I am antagonistic to the proposal, I'm just trying to determine if it is a lack of expressive power in the original coroutine specification, or a syntactic nicety.

NeilThis message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.