>> Again, though, you never want to muck with continuations directly! >> They're too wild. You get an expert to use them in the bowels of an >> implementation of something else. [Christian] > Maybe with one exception: With careful coding, you can use > a continuation at the head of a very deep recursion and use > it as an early break if the algorithm fails. The effect is > the same as bailing out with an exception, despite the fact > that no "finally" causes would be obeyed. It is just a > incredibly fast jump out of something if you know what > you are doing. You don't need continuations for this, though; e.g., in Icon I've done this often, by making the head of the deep recursion a co-expression, doing the recursion via straight calls, and then doing a coroutine resumption of &main when I want to break out. At that point I set the coexp to &null, and GC reclaims the stack frames (the coexp is no longer reachable from outside) when it feels like it <wink>. This is a particularly simple application of coroutines that could be packaged up in a simpler way for its own sake; so, again, while continuations may be used fruitfully under the covers here, there's still no reason to make a poor end user wrestle with them. > ... Well, I admit that the continuation approach is slightly too much > for the coroutine/generator case, It's good that you admit that, because generators alone could have been implemented with a 20-line patch <wink>. BTW, I expect that by far the bulk of your changes *still* amount to what's needed for disentangling the C stack, right? The continuation implementation has been subtle, but so far I've gotten the impression that it requires little code beyond that required for stacklessness. > ... > How about "amb"? :-) > (see "teach youself schem in fixnum days, chapter 14 at > http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme-Z-H-15.html#%_chap_14) That's the point at which I think continuations get insane: it's an unreasonably convoluted implementation of a straightforward (via other means) backtracking framework. In a similar vein, I've read 100 times that continuations can be used to implement a notion of (fake) threads, but haven't actually seen an implementation that wasn't depressingly subtle & long-winded despite being just a feeble "proof of concept". These have the *feeling* of e.g. implementing generators on top of real threads: ya, you can do it, but nobody in their right mind is fooled by it <wink>. > About my last problems: > The hard decision is: > - Either I just stop and I'm ready already, and loops are funny. OK by me -- forgetting implementation, I still can't claim to know what's the best semantic here. > - Or I do the hidden register search, which makes things more > complicated and also voidens the pushback trick partially, > since then I would manage all stack stuff in one frame. Bleech. > - Or, and that's what I will do finally: > For now, I will really just correct the loops. > > Well, that *is* a change to Python again, but no semantic change. > The internal loop counter will no longer be an integer object, > but a mutable integer box. I will just create a one-element > integer array and count with its zero element. > This is correct, since the stack value isn't popped off, > so all alive stack copies share this one element. Ah, very clever! Yes, that will fly -- the continuations will share a reference to the value rather than the value itself. Perfect! > As a side effect, I save the Object/Integer conversion, so > I guess it will be faster. *and* this solution does not involve > any other change, since the stack layout is identical to before. Right, no downside at all. Except that Guido will hate it <wink>. there's-a-disturbance-in-the-force-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4