Re: NRE committed: PLEASE TEST

On Tue, 02 Sep 2008 19:41:54 -0300,
miguel <msofer@xxxxxxxxxxxx> wrote:

Fredderic wrote:
miguel <msofer@xxxxxxxxxxxx> wrote:
As currently implemented, it would also prevent the second and
later calls to take more than one argument.
Dare I ask, why? ;)
Yup: the argument to the coroutine is the return value of the [yield]
that suspended the previous invocation. A design decision - may be
good, may be bad.

I used to think wrongly that [coroutine]s command was always going to
be a proc, and hence you could pass in arguments and have them update
the corresponding variables with each resume. But I think I'm better
now. ;)

Okay, so you give an argument to the coroutine and it pops out as the
return value of [yield]. Sounds about perfect to me. Just one
question; is it just one word, or a list of the words given to the
coroutine...?


I presume there'll be an [info] sub-command to tell us whether
we're in a [coroutine] or not...?
What is required for [info] is still an open question. Also a way
to query if a given command is a coroutine or not might be useful.
Or if [yield] will succeed. (as opposed to catching it). I'm
waiting to see what the users need.
HEAD now has ::tcl::unsupported::infoCoroutine (will become [info
coroutine] eventually) that returns the FQN of the coroutine's
command (and {} when not in a coroutine; I know, no {}-named
coroutines).

Not necessarily... A list containing an empty string is different from
an empty list.


I'm not 100% sure this isn't being discussed in the core group... But I
think it was said that the coroutine runs at global level (#0)...? Is
that a design decision, or a practical limitation? I'm asking because
since you can pass in arguments to the coroutine (a Good Thing!), how is
[upvar] going to react? For example in this type of construct;

coroutine coincr apply {{} {
while { 1 } {
uplevel 1 incr [yield $count] [incr count]
}
}}

will doing [coincr fuya] work? (Ignoring for the moment whether the
return value of [yield] is a single word or an args-style list of
arguments.)


I wonder whether it would be sane to add an [info lambda] command
that will compile and return a proc as a lambda expression...?
I still think that would be handy, btw... Essentially this;
proc info::lambda {proc} {
set args [list]
foreach arg [info args $proc] {
if { [info default $proc $arg def] } {
lappend args [list $arg $def]
} else {
lappend args $arg
}
}
return [list $args $body]
}
(Probably needs some [namespace] magic too...)
Uhh? I think it might make more sense to do things the other way
round, actually: interp alias {} $proc {} ::apply $lambda

That's pretty off topic anyhow, really, it was more a musing because
[info args] is half-way useful, but [info default] is just a pain in the
proverbial buttocks. So I was thinking it'd be nice to have an [info]
command to compliment [info proc], [info body], [info args], and [info
default] by returning a fully-built lambda, retaining the bytecompiled
version of the proc if it exists (assuming doing so is even possible).

Back before I was enlightened (ie. when I wrote that last post) it
seemed a little more useful than it does now. Still, trying to
construct a lamba that matches an existing proc is still a pain in
those buttocks I mentioned just before. [info lamba] could potentially
share everything with the proc it originally came from making it
extremely light-weight and avoiding the need to re-compile it all over
again and again and again. Where it might still be useful, though, is
making it really easy to pass a proc to another thread...


--
Fredderic

Elephant = mouse built to government specs

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 62 days, 2:56)

.