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: Sat, 13 Apr 2013 12:12:02 +0200 Message-ID: <1725031.6ll3YGeLN9@warperdoze> References: <26254241.alHDNf9hMe@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 1365847936 12687 80.91.229.3 (13 Apr 2013 10:12:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Apr 2013 10:12:16 +0000 (UTC) Cc: guile-devel@gnu.org To: noah.b.lavine@gmail.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Apr 13 12:12:20 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 1UQxRS-00065C-HI for guile-devel@m.gmane.org; Sat, 13 Apr 2013 12:12:18 +0200 Original-Received: from localhost ([::1]:53602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQxRS-00076Z-2d for guile-devel@m.gmane.org; Sat, 13 Apr 2013 06:12:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQxRL-00076H-D1 for guile-devel@gnu.org; Sat, 13 Apr 2013 06:12:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQxRK-00015f-Di for guile-devel@gnu.org; Sat, 13 Apr 2013 06:12:11 -0400 Original-Received: from mail-lb0-f175.google.com ([209.85.217.175]:46871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQxRK-00015P-61 for guile-devel@gnu.org; Sat, 13 Apr 2013 06:12:10 -0400 Original-Received: by mail-lb0-f175.google.com with SMTP id o10so3298504lbi.20 for ; Sat, 13 Apr 2013 03:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=w741GwE05ebt8gq4NjJWKHYMioI2LRyjhTQ+ydJ5ZmY=; b=fpZPNLLbKOp6tyNyC9IKzWztgRjFKsaetMamUgtzgZnpmkOqvG4t7udq2IwzR335lD Wd1Hn4G8NPb15FtG4K6sauIZoqKpXWV0KWoG6vfbHeYXcG/PxvudeYgYSAV0eIjP7Dmq d2EbeeEV/nzFWMuBUY1fT1QreTAAqoEPG9JxpBzMYawKP4wKDAONuvE4bw1QWH5OzoJt +04lEzeAvqia3Iaj2ztjNPsQOS1c0LIBR/gT23GLIlqzLD+KsVve18z1xnJgFW7VTMj+ GzrhhitBPfJLK+0v+rDM0yoZGCBa4hEA06x6lz5GQRHF0+O5oHihc573zhGZCsS4Tdhu PKYg== X-Received: by 10.112.42.37 with SMTP id k5mr6903569lbl.49.1365847928592; Sat, 13 Apr 2013 03:12:08 -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 10sm4623058laq.8.2013.04.13.03.12.06 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 03:12:07 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; x86_64; ; ) In-Reply-To: <26254241.alHDNf9hMe@warperdoze> 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:16238 Archived-At: Hi Noha, You asked of one example where fluid-let is not suitable. Well, one key component of redo-safe-variables is that it's composable with delayed compilation. Consider a two pass compiler, where in the first pass closures are created and then in the next pass they will be evaluated with arguments and lead to the final code. If we would like to have user interaction in this and in pass 1, store and then redo a state, the result would be as expected. Not so if the variables are backtracking. No over to the general discussion: ---------------------------------- I have spend a lot of time in guile-log, thesting out the redo-safeness properties and got it working with respect to user interaction and the use-cases in described in the spec that I send to the list. Then I spend time cleaning up guile-log and documenting. Now I've come to the postpone logic and things get's really interesting. The postpone module will let you store a set of states representing choice points, then evaluate some heuritstic leading to an index describing the liklihood of success in that branch and then it will sieve out the most likly branches and continue with them. The imlpementation was well tested and worked quite ok in the guile-unify repo. But it has bitrotten quite a lot and need a rewrite. So I read the code and analyzed the old behavior in the light of redo-safe variables and parameters. My conclusion is twofold. * The choice of doung the guard at the binding is not enough and the spec is well thought out for redo-safe-variables but not redo safe parameters. The reason is that the most effective way of storing the states is to keep a memory tree of the states and make sure not to keep duplicates in memory which would be the case if we stored a set of lists. Essentially you would use it like (let ((a 1)) (any (with-redo-variables ((a 0)) (set~ a 2) P1) (with-redo-variables ((a 0)) (set~ a 3) P1) ...)) In stead of (let ((a 1)) (with-redo-variables ((a 0)) (any (all (set~ a 2) P1) (all (set~ a 3) P2) ...))) The first is needed in the postpone because we do not backtrack over the guard when we store the state. Which we will do at a user interaction use case and there the second form is enough. Conclusion: We need to add this postpone use case and decribe it in the spec and point at it for the rational behind the with-redo-variables guard. Also we need to change the semantics of redo safe parameters. ** Another optimization is that it is much cheaper to reistate the same memory the second time e.g. we will reuse what we did before and hence cons much less. This can have a dramatic effect on the speed of any-interleave and hence is an important optimization. But note that the same guard will save a new state everytime it backtracks which was assumed to be unclean but of any much high overhead. But in the light of the above optimization it will hinders the ability to reuse old infromation becase it is a linked list and it's not possible to exchange one element in the list. It's better to add a check and the unwind part of the guard to actually store the state when in that mode e.g. that there is essentially two types do the abort, in a saving-state, mode, or keeping the state mode. This way only direct postpones will be affected but not ordinary uses of any-interleave. Conclusion: We need to ad a check in the unwind part as well. /Stefan