From: Lars H. <Lar...@re...> - 2012-03-29 21:48:52
|
Andreas Leitgeb skrev 2012-03-29 18.22: > miguel sofer<mig...@gm...> wrote: >> As to #383: I would say that the main issue is that it was not discussed >> much. My take: useful, lightweight and simple. > > If the purpose is aiding debugging, then I'd think that enhancing > [uplevel] to allow targeting a running coro1, by specifying a target- > level of "##coro1" would be much simpler to use. Not a running coroutine, but one which is suspended (has [yield]ed). There could be any number of these, and there is no order on the set of them, so there is no sense of a level that could be used to address one of them. Folding this into [uplevel] is an interesting idea, which has the merit of suggesting the right way of thinking about the feature, but I suspect some people might be horrified by the notion. > If the coro had called another procedure and yielded from within that, > then uplevel would target the stack-frame of whereever the yield happened. > (from within the uplevel ##coro1 scriptlet, further uplevel-calls could > then traverse the coroutine's full stack.) > > The usecases from the TIP fall in these categories: > 1.) stuff that would be much easier and clearer with an uplevel > approach: inspecting local vars, stack frames, ... Yes. > 1a.) allowing for a particular subtle variant of externally > terminating the coro under some rather odd circumstances. > If a coro has a need for such an extra exit, it should have > it explicitly coded, rather than rely on debugging features > to trigger it. > Also, with uplevel you could still infer the particular > clean-up stuff, then do [rename coro1 {}], in case of an > unexpected need for such a manipulation. A more common use-case for that aspect of the TIPped mechanism would be to have the coroutine [break] out of a loop in which it has gotten stuck due to some data structure being corrupted. But this is still more the exception than the rule. On the script level, it seems reasonable that a [tailcall] within a [coeval] script could have (or at least be given) the effect of "escaping into the coroutine proper" and thus make coeval $coro {tailcall break} equivalent to the TIPped coinject $coro return -code break -level 0; $coro but I don't know if it's that easy on the C side. > 2.) similar to a proc-entry trace, but "one-shot": I haven't yet > used proc-entry traces, but if the feature makes sense for > coros then rather add traces for coro-resumption; in line and > consistent with the execution traces we already have. Or just trace the coroutine-command itself. > The part about $resumearg will be ugly if not impossible to adapt > to the new yield/yieldto "return-type" dichotomy, anyway. Yes it is ugly, but I don't think TIP#396 has made it worse. Some of the other multiple-arg proposals would have, however. Lars Hellström |