Re: NRE committed: PLEASE TEST

Fredderic wrote:
miguel <msofer@xxxxxxxxxxxx> wrote:

Fredderic wrote:
[yield] would be a handy way to allow a [proc] to do some
initialisation on first run.
Oh - now I understood what you mean. This would make procs a bit
heavier than coroutines (see below).

I kind of figured that, and pretty much wiped that idea myself.

My wish here would be served by the [coroutine] command being able to
displace an existing proc or command until it completes. Having
[coroutine] displace the current proc with an inline [apply] invocation
(as DKF mentioned is possible), would allow exactly the semantics I was
rather hoping would be possible. A proc could then trivially be built
that can [yield] without having to be explicitly invoked through
[coroutine].

A limitation of this approach is that you couldn't have 2 or more simultaneous coroutine instances based on the same command. Another difficulty is that the original proc may take different arguments than the resume command. You should be able to write something like this if you want, though:

proc coproc {name params body} {
set f [list $params $body]
interp alias {} $name {} coproc:spawn $name $f
}
proc coproc:spawn {name f args} {
coroutine $name ::apply $f {*}$args
}

(restoring the original proc left as an exercise).

As currently implemented, it would also prevent the second and later
calls to take more than one argument.

Dare I ask, why? ;)

If you think about how the mechanism works, a coroutine suspends from a yield, and is later resumed from that place. Any arguments to the resume become the result of the yield as far as the coroutine is concerned:

set next [yield $val]

Therefore, if the resume command could take multiple arguments then it would be impossible to distinguish between multiple separate arguments and a list. You could maybe extend yield, something like:

yield $val here are the resume args

but I think the original is sufficient.

[...]

My focus on this issue, btw, is mostly in the interest of allowing
coroutines to be used as an implementation detail in the construction
of a proc, rather than a project-wide design decision from the outset.
I think _if_ it can be done without too much effort, it would be a
fantastically handy way to do the first-run initialisation thing.

Coroutines should be possible to use as an implementation detail, as in my worked example converting a simple synchronous program to use the event loop: http://wiki.tcl.tk/21532

-- Neil
.

Relevant Pages

  • Re: NRE committed: PLEASE TEST
    ... command and the underlying mechanics of the coroutine mechanism, ... if the coroutine command itself can do something useful with its ... whereas the original proc takes only 1 argument, ...
    (comp.lang.tcl)
  • 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
    ... value of the [yield] command. ... TCL has this wonderful new command called. ... don't force everyone to construct wrapper functions to use ... coroutine, and modern improvements in the byte compiling are making the ...
    (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
    ... 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)