From: Colin M. <co...@ch...> - 2010-04-15 22:52:39
|
Donald G Porter wrote: > Colin McCormack wrote: >> Invocation of a coroutine should accept multiple arguments,... > > Would this change have any noteworthy consequences on the ability to > combine coroutines and ensembles? > I can see few ways in which ensembles and coroutines can be combined. The first is to construct a coroutine as an element of an ensemble, either (say) a simple element or a [namespace unknown] handler. The change makes no change to this ability, except insofar as it permits a coro where a multi-arg'd command would otherwise be. This is a good thing for the same reason multi-arg'd proc commands are a good thing. The second way is to address an ensemble with a coroutine constructor. Currently it's not permitted to invoke that coroutine with more than one argument, therefore it would be impossible to represent an ensemble call to any non-niladic component command without currying. It should be possible to construct a dispatcher command within an ensemble which proxied any ensemble calls (as coro invocations) and returned their results via [::yield] instead of [::return], interpreting the result of that ::yield as a new ensemble invocation. The third way is to address an ensemble via an explicit proxy coroutine, such that the proxy mentioned above isn't part of the ensemble, and merely functions as a dispatcher. Again, the ability to specify more than a single argument would mean that one could call any ensemble command (not just the niladic ones) without currying. As I have used coroutines, they often have a top-level command which interprets invocation args as commands, interpreting the first element of a passed list as a command to invoke. I imagine this would continue to be a fairly common pattern of use. This 'dispatcher'-style coroutine effectively behaves like an ensemble insofar as it accepts calls and performs commands much as an ensemble does. It doesn't provide for the assembly of sets of commands as ensemble does, but nor should it, as [namespace] performs that function admirably. I don't think this change would make any significant change to the relationship between coro and ensemble, except for the stated objective of allowing for more arguments. The significant benefit of this change is to the caller of a coroutine command, by making it possible to pass multiple values as arguments in the usual Tcl style, and thereby permitting the an author to simulate any existing Tcl command with a coroutine. Colin. |