Re: NRE committed: PLEASE TEST

On Tue, 19 Aug 2008 06:44:31 -0700 (PDT),
john roll <john@xxxxxxxxxx> wrote:

I see in the above example that you've moved the initial yield into
the body of the coroutine call to clear it out of the iota routine
proper, but I'm asking the more fundamental question, why have an
initial execution of the script passed to the coroutine command at
all? Why not just build the coroutine command immediately? Will this
feature be useful elsewhere?

I think it makes sense to think of the usage pattern like this:

proc my-coroutine {args} {
initialisation
yield
# main functionality starts here
while {some-condition} {
calculate-value
yield return-value
}
}

In the simple iota example, then, you can read it simply as there being
no initialisation part.


Personally, I think it would make more sense if [yield] would function
regardless of whether the proc was evaluated via [coroutine] or not,
rather than throwing an error. You could still use [coroutine] to
create simultaneous invocations, and unlike a [coroutine] invocation,
the original proc it would essentially "reset" when it completes.
Basically acting exactly as though it was storing internal state in a
private global variable between runs.

Failing that, I think [coroutine] should work exclusively on lambda's
and not [proc]s at all, to highlight the fact that you seemingly can't
really use them in interchanged contexts; a proc with [yield]s won't
work too wekk when invoked directly rather than via construction by
[coroutine], and a proc without [yield]s doesn't make much sense to
invoke through [coroutine]. So you'd take a lambda style
function-in-a-variable, and use [coroutine] to create a command out of
it, which would then be used instead of invoking the lambda via apply.


That's my take on it, anyhow... Other than that little issue, I think
it's pretty damn awesome, and will help make an awful lot of
client-server type code MUCH neater.


--
Fredderic

Longhorn error#4711: TCPA / NGSCB VIOLATION: Microsoft optical mouse
detected penguin patterns on mousepad. Partition scan in progress to
remove offending incompatible products. Reactivate your MS software.

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 47 days, 10:49)

.

Relevant Pages

  • Re: NRE committed: PLEASE TEST
    ... to displace an existing proc or command until it completes. ... that [yield] would only effect the proc it was invoked from). ... If the original command has been replaced by a default coroutine, ...
    (comp.lang.tcl)
  • Re: NRE committed: PLEASE TEST
    ... function regardless of whether the proc was evaluated via ... use [coroutine] to create simultaneous invocations, ... IOW, your proposal may look like "let us change [yield], but ir really is "let us change ". ... is whether there's anything within the TCL stack ...
    (comp.lang.tcl)
  • Re: NRE committed: PLEASE TEST
    ... be a proc, and hence you could pass in arguments and have them update ... so you give an argument to the coroutine and it pops out as the ... that a design decision, or a practical limitation? ... foreach arg [info args $proc] { ...
    (comp.lang.tcl)
  • Re: NRE committed: PLEASE TEST
    ... My wish here would be served by the command being able to ... displace an existing proc or command until it completes. ... A limitation of this approach is that you couldn't have 2 or more simultaneous coroutine instances based on the same command. ... If you think about how the mechanism works, a coroutine suspends from a yield, and is later resumed from that place. ...
    (comp.lang.tcl)
  • Re: NRE committed: PLEASE TEST
    ... resume only takes a single argument, whereas the original proc ... Creation of a coroutine takes inital arguments - fair enough - and resuming a coroutine also takes an argument. ... From the Tcl script level it is indeed a command, and it does take an optional argument. ...
    (comp.lang.tcl)