On Fri, 5 Nov 2004, Zbyszek Jurkiewicz wrote:
> > I don't see a problem in re-doing the unwind-protected stuff once again. > > Sure, this would mean that unwind-protect and continuations could not be > > mixed as freely as one might want. But what one would like to have in the > > end is dynamic-wind, anyway, so I really do not see why this particular > > maybe-not-so-nice linguistic feature of CL should bar the introduction of > > a different very powerful and useful concept. > > > > As for as I know, there are many problems when definining the semantics > of dynamic-wind correctly in Scheme. Fo example, assume you opened some > file when entering it for the first time (and closed when leaving > dynamic-wind scope). Now you reenter by continuation, but the file does > not exist -- you cannot say you are in the same computation context. For sure. What we see here is nothing else than the problem that the timeless functional world and the real world in which things change do not mix too well. The patient says "Doctor, it hurts when I do this." "Then don't do that!" For the functional part of my code (and not only mine), call/cc would be a terrific tool. I do not want to use it in conjunction with non-functional state change, and strongly suppose no one else with sound reasons to think about using call/cc in one situation or another will. So, where's the problem? > One may try to prevent removing files for which access by cotinuation > exists, but what would you do if the file is on remote computer and > this computer has been switched off in the meantime. Come on. Let me use this analogy: It is possible to ptrace-attach a running process and use this to hand in code for a special signal handler that does funny things, like closing file descriptors that are currently in use. Does this mean the file descriptor concept is badly flawed and cannot be used? > For me, dynamic-wind has MUCH MORE power than unwind-protect, because it > is the construction for reentering previous computation contexts. > On the contrary, UNWIND-PROTECT only serves to safely leave contexts, so > it has much simpler semantics. I doubt we want to have dynamic-wind in > place of unwind-protect in CL, at least not until Scheme community comes > up with verifiable full semantics for dynamic-wind :-(and I doubt, whether > it is possible to define all kinds of side-effects and how to reasonably > restore the state for them). Isn't it obvious that one just cannot do that? Therefore, an "if you do this, the behaviour is undefined" should suffice for the people that actually want to solve real-world problems with continuations. If you really have to formally specify behaviour there, just let it be non-termination. In one project, I am experimenting with using a (you would say: much cleaner) monadic approach a'la Haskell as an alternative to continuations. This seems to work quite well, but I still have not made up my mind whether this is always the best way to attack situations where one might want to use continuations. -- regards, [EMAIL PROTECTED] (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)
