Re: NRE committed: PLEASE TEST

On Wed, 03 Sep 2008 20:19:33 +0100,
Neil Madden <nem@xxxxxxxxxxxxx> wrote:

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.

Not at all... The musings I muttered on coroutines ages ago over on
the wiki were along these lines (with the unenlightened assumption that
[yield] would only effect the proc it was invoked from). In those
musings a [coroutine] command would be used to explicitly create a
simultaneous instance until a new name, where the original command
would simply resume the default one. No reason the same couldn't be
applied here.


Another difficulty is that the original proc may take different
arguments than the resume command.

Actually that came out rather cleanly in the wash. The original proc
takes initialisation arguments, while the resumed coroutine gets any
arguments via the return value from [yield]. Unless it takes specific
action, those arguments will be ignored in the resuming case anyhow.


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]

I believe I just said that as the answer to your prior question. ;)


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:

No. You simply ALWAYS return a list, ala [proc]s special "args"
argument. It might be slightly inconvenient, but it's an awful lot
more convenient than not being able to do it at all. There are other
possibilities also, such as allowing [yield] to take an arguments list
after the return value. A bit odd, but it's an idea if you're
desperate. ;)

Besides, I'd still love to see {n} be synonymous for [lindex n], which
would make that issue a whole lot less annoying. ;)


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

It gets a little more complicated when you're not writing the entire
application from scratch. When you're trying to retro-fit new ideas
into old code (which I tend to do a lot of), things get a little more
interesting.


--
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 63 days, 2:39)

.

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
    ... 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)
  • Re: NRE committed: PLEASE TEST
    ... function regardless of whether the proc was evaluated via ... use [coroutine] to create simultaneous invocations, ... But [yield] would be a ... swap in the new execEnv as the current execution environment, ...
    (comp.lang.tcl)