> Daniel Writed > Dynamic states are not suitable for the purpose. They have nothing to > do with compenstating for the inability of continuations to backtrack > _through side-effects_. I believe this will be obvious if you > consider the problem of side-effects generally, rather than focusing > only on variable assignment. Yes, I try now to avoid dynamic states. I was a bit ignorant of the subject. But after some reading and thought your point has become clear to me.
> Backtracking is typically handled (at least, in part) by the > evaluator, by either: > - explicitly tracking side-effects, so that they can be reverted in a > sensible manner; or > - state-copying, that is, non-mutable environments. Yea I have thise two features on my mind when trying to design a spec. > I do not see how you can hope to marry the concepts of continuations > and backtracking side-effects without modifying the evaluator, at > which point you have continuations and an evaluation environment that > is not Scheme, although perhaps very Scheme-like. Note that there is a guard that checks if you should restore or not. If that executes always to #f then everything is scheme, so it is an extension. Actually I'm not sure if I need to change the evaluater to get redo-safe-variables I beleve that you can get the features by simply modify call/cc with current scheme. But for redo-safe-parameters I do not know if the same holds. Also the latter part of the spec handling set! and set~, AS Noha stated in his last mail. We might just drop that part and have a recomendation for macro writers to follow a certain pattern instead. > It seems your real objective is to extend Scheme-embedded logic DSLs > by supporting continuations and non-functional Scheme code within > them. I appreciate that you have some experience in the area, can you > point to any papers that discuss anything similar to what you are > trying to achieve? (Not the Scheme modifications, but the logic DSL + > side-effects + continuations). I'm afraid that I have not seen any papers on this. But I'm not in academia and have not a great overview of the subject. Maybe I should write a paper about guile-log, maybe I should try to dig up a references. Maybe I should documnet guile-log at a very detailed level. > Back to the Scheme modifications. Perhaps I do not understand that > problem space as well as you, but when I look at this I see a > premature attempt to solve a problem that is _hard_. There is also no > precedent for continuations that backtrack side-effects in any Scheme > or Lisp I know of, and noone will miss that if you do not acheive it. > Clearly you are spending some effort on this, and I do not like to see > anyone wasting efforts. IMO this specific path is unproductive. Yea that path is unproductive, right now I pursue other paths. To be onest, I do this mainly to learn. But also because I find it interesting and useful. The hard part actually seams not to implement something that are redo safe. The hard part is to do it in a way so that you will get easy to reason about code and possible efficient imlementations. Much of the confusion is attributed to this. /Stefan
