Re: NRE committed: PLEASE TEST

Fredderic wrote:
On Thu, 04 Sep 2008 12:37:03 -0300, miguel <msofer@xxxxxxxxxxxx> wrote:

Fredderic wrote:
Heck, talking about the present implementation you're so eager to defend,
is that single argument to the coroutine optional? (I haven't noticed it
actually stated in the thread one way or the other.)
It is optional - if none is supplied, {} is assumed.

That's what I figured. And as I said, I understand why it was done that way,
and it's fine during conception. Simple, easy, safe.


The coroutine argument (as seen from outside) is just the return value of
the [yield] command (as seen from inside). That's why it is one argument
defaulting to {}: just like [return].

But [return] doesn't only return a single value. It actually returns two
values, and in one case (-code error), even more. So perhaps it wasn't such
a good example.

Uh? Are we both talking about Tcl? Absolutely EVERY command returns a single
value. Look at the api, Tcl_GetObjResult(). Or do try at the console to give
[return] more than one result argument. Or look at the man page at
http://tcl.tk/man/tcl8.6/TclCmd/return.htm

I think you are confusing a command's result with a lot of other things that a
command can do: set the return code, change some state, set some variables, open
a file, send an email, ...

For one, TCL has this wonderful new command called [lassign]. And in case
you didn't feel like reading my response to Neil (who I've noticed has a
tendency to follow rather than make his own path), [yield] isn't a command
that performs a task and returns a value. It is one part of a whole new
concept in flow control, and should be treated as such.

Sorry to disagree: Tcl only has commands that "perform a task and return a
value". I do not think I want to change *that*.

Please, don't force everyone to construct wrapper functions to use their
coroutines (resume), and then wrapper functions to make using the wrapper
functions easier (interp alias ... resume ...), and yet more wrapper
functions to make the wrapping mechanism itself easier to use (that actor
stuff Neil was going on about). It's getting kind of ridiculous.

Hmmm ... I do not think that everything should be coded in C; a library of
wrappers for some typical uses could be in tcllib, or even provided in a default
installation (similar to ::unknown, or via [package require]).

That is: the C implementation should IMO enable all (at least many) uses; which
one it "prefers" in the sense of not requiring wrapping is a decision that involves
(a) expected frequency of usage
(b) required performance for each usage
(c) simplicity of core code
(d) opinions

I'd be reluctant to have too many variants in the core, it's way better to have
the enabling mechanism in core and syntactic sugar in tcl wrappers. IMHO.

I would appreciate if you would provide concrete sample usage patterns (in the
wiki), together with the required "wrappers", so that we can properly weigh them
against other usage patterns.

Or maybe a description or prototype man page for what you want? Along the lines
of http://msofer.com:8080/wiki?name=Coroutines would be fine, I guess.

But maybe you mean by "don't force everyone to construct wrapper functions" that
there is one variant that does the right thing for every use case?

It is absolutely trivial to extract arguments from a list within the coroutine, and modern improvements in the byte compiling are making the performance impact more and more insignificant. It's often much less trivial, however, to wrap those arguments up in the first place, as is evidenced by all those wrappers I just mentioned. I would much rather use
one [lindex] on the inside, than three entirely new commands on the outside.

And as I said to Neil, you're saying that the the coroutine command should
take one argument because [yield] returns one argument. So why can't [yield]
be changed to take a formal argument list in addition to the argument it
returns? From the implementers point of view, it requires more work. But
from an API point of view, I'd say it's an awful lot more "correct". And if
it's okay to wrap the coroutine command (in two layers no less!), why isn't
it equally okay to wrap the [yield] command?

Who said it's not OK? You can wrap every command in Tcl, why would this one not
be ok?

proc yield1 {value} { set list [yield $value] if { [llength $list] > 1 } {

Oohhhh ... I'd be tempted to resume with an argument "\{" just to make you crash

error "I'm too sexy for this command." } return [lindex $list 0] }

proc yieldX {value args} { set list [yield $value] return [uplevel 1 [list
lassign $list {*}$args]] }

Uhhh ... I'd really not wrap this one, how about the perfectly clear

lassign [yield $value] foo1 foo2 foo3

(apart from the crash if resumed with a non-list, of course)

proc yieldN {value args} { set list [yield $value] if { [lindex $args end] eq
"args" } { set args [lrange $args 0 end-1] uplevel 1 [list set args [list
lassign $list {*}$args]] return [llength $list] } }

Take your pick. (Utterly untested, of course...)

Please do test it - give some code we can analyze to try to understand what
you're saying, and most importantly what you want to do. What are the use cases
for these things? How come you are not complaining about (say) [eval] requiring
wrappers to do similar things?

You really got me confused when you started talking about [yield]'s formal
arguments, I thought all the while we were talking about the resume command's
formals (and how they map to [yield]'s return value).

Yet again everyone seems to be so focused on explaining why the current state
of things is right, they're blind to why it isn't. You, I can sort of
understand. It's your baby, it means more work for you to change it, etc.
Heck. Post the relevant code snippet in your reply, I'll write the changes
(maybe I'll even do it half as well as you would), and you can paste it right
back into your source again. Though I suspect it's trivial enough a change
that it'd be less of a PITA to you for you to just do it yourself.

The current state of things is EXPERIMENTAL, not right or wrong. Are you doing
experiments, testing the functionality on actual use cases? That'd help both
debug the damn thing and decide on what the best api might be.

As to the "relevant code snippet": the thing is in cvs at
http://tcl.cvs.sourceforge.net/tcl/tcl/, help yourself. The relevant code is at
the end of generic/tclBasic.c

But the problem is *not* the work to implement. It is deciding what is the best
option. You seem to have a strong opinion, but your arguments are not coming
through clearly enough. If you want to convince, provide use cases.

I did not see myself as defending anything, just explaining what's in the core -
and why I took some design decisions. I can still be convinced that they're not
optimal. That is possibly the main reason why the thing is not TIPped yet.

And finally, if you don't, how long after it goes mainstream do you think
it'll be before people start asking for the coroutine command to take
multiple arguments, anyhow? Once it looses its shine, people are going to
start looking for ways to improve it, and I'm pretty darned sure this'll be
one of the first things they'll come asking for. Then it'll be another round
of TIPping, compatibility issues, so on and so forth.

Don't know, really. How would people be using them? Will there be many uses with
multiple arguments and where [list]-wrapping them is too clumsy? More than the
use cases where the [lindex] is a PITA? Is this in apps where indirection
through a wrapper is unacceptably slow (but direct calling is not)?

Unless, someone can tell me what extra arguments the coroutine command might
sanely have, that wouldn't be better placed in, for example, a separate
[coroutine configure] type command. And even if there does turn out to be
something, it'd be trivial to wrap that. It's certainly not going to be the
major use case!

.

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
    ... 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
    ... 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
    ... 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)
  • Creating Python class wrapper for a command line tool
    ... I was wondering what would be the most elegant way for creating a Python class ... wrapper for a command line utility, which takes three types of arguments: ... when you call the program from command line it looks like ...
    (comp.lang.python)