sil...@gmail.com wrote:
> On Saturday, May 26, 2018 at 2:08:49 AM UTC-3, Rich wrote:
>> Well, if is possible to write without coroutines and without globals.
>> And 'without a second proc' if one does not consider an anonymous proc
>> a 'proc' per se.:
>
> That is interesting and is related to something I was thinking about.
> I actually cannot see where coroutines help a lot, specially in Tcl,
> which has other useful features.
Well, keep in mind that while it is /possible/ to implement without
coroutines and without globals, that the actual implementation is very
likely to not be the most efficient one. Redefining the target lambda
of the fileevent for the channel is likely to be a performance killer
overall. So don't confuse /possible/ with /efficient/, the two are not
always the same.
The coroutine version is likely to be much more efficient at the
specific task than my hack.
> For example, I can see it have two main uses:
>
> 1. Implement the "suspend" feature Rich explained;
>
> 2. Implement asynchronous function calls.
>
> 1. can be solved by a proc and a global variable. This seems ugly
> but Tcl has enough features to allow us to implement the same concept
> in more elegant ways, like namespaces and TclOO (with a object
> variable, for example).
>
> 2. can be done with [after idle {code}]
>
> So that is not very clear for me where coroutines really help.
A big reason espoused on many of the wiki pages is that coroutines
allow for writing event driven code in a sequential style (so it looks
and reads reasonably sequentially) while hiding the async. nature of
the event drive aspect.
Typical event driven code is generally a disconnected set of procs that
get called in arbitrary orderings, and so mapping out (and
understanding) the control flow from the source can become quite a
challenge.
Being able to 'unwind' that into a sequential looking layout, while
still having the event driven nature, can be a huge help to making
blocks of code more understandable.