From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: redo-safe-variables and redo-safe-parameters Date: Mon, 01 Apr 2013 12:17:16 +0200 Message-ID: <1519320.kv9yxKJiCU@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1364811449 2957 80.91.229.3 (1 Apr 2013 10:17:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Apr 2013 10:17:29 +0000 (UTC) To: mandyke@gmail.com, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 01 12:17:57 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UMboL-0002LK-21 for guile-devel@m.gmane.org; Mon, 01 Apr 2013 12:17:57 +0200 Original-Received: from localhost ([::1]:38394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMbnw-00089K-H7 for guile-devel@m.gmane.org; Mon, 01 Apr 2013 06:17:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMbnr-000893-8I for guile-devel@gnu.org; Mon, 01 Apr 2013 06:17:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMbnm-0006jR-2o for guile-devel@gnu.org; Mon, 01 Apr 2013 06:17:27 -0400 Original-Received: from mail-lb0-f175.google.com ([209.85.217.175]:38683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMbnl-0006jB-RO for guile-devel@gnu.org; Mon, 01 Apr 2013 06:17:22 -0400 Original-Received: by mail-lb0-f175.google.com with SMTP id o10so1802284lbi.34 for ; Mon, 01 Apr 2013 03:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=dkuvwZ60bUS/cnQHa70lpm1LfE2AKpBNt6bwqQlMgwo=; b=FltCWdX22TYIJl02Pyp7y++jSR4lGYO5kkYwx8hTBkDWxAQ29fy/l1bPindNJF6KT5 aGMmFGjWSfwQzaF2Rh9QqVKed7jJtZVr+bgKI2WNmeCJbQH5hNg7xe+C1i17HVdYny6K kZJJYWa8KNJrfuzbVXqIbxKmePwCwIhNr/2PE+j8MemzGWXKJTo3lKrgOE7oOofZBlR5 io3wnn0PCriOcQ1Mlwa9CWCq8yIDzuhy2815Nf5CbTfFk5OjZByhWX/V0EmTJ+P5sq/o DQsoXTWSqopp5SG4IC+tZKTlDvBRfbI98MJx3ed6W/AGT5U/Y/ipihHJhr2UeD8g91f4 YP9Q== X-Received: by 10.112.25.8 with SMTP id y8mr5548483lbf.81.1364811440847; Mon, 01 Apr 2013 03:17:20 -0700 (PDT) Original-Received: from warperdoze.localnet (1-1-1-39a.veo.vs.bostream.se. [82.182.254.46]) by mx.google.com with ESMTPS id jh4sm5346383lab.7.2013.04.01.03.17.18 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 03:17:19 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; x86_64; ; ) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.217.175 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16090 Archived-At: > 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