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: Tue, 26 Mar 2013 21:43:57 +0100 Message-ID: <4099741.BPvjEG9t1k@warperdoze> References: <13378334.Jv25yq6OaM@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 1364330651 14330 80.91.229.3 (26 Mar 2013 20:44:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 20:44:11 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 26 21:44:38 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 1UKajU-0000cl-P2 for guile-devel@m.gmane.org; Tue, 26 Mar 2013 21:44:36 +0100 Original-Received: from localhost ([::1]:53575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKaj6-0004bY-TE for guile-devel@m.gmane.org; Tue, 26 Mar 2013 16:44:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKaj2-0004bK-Go for guile-devel@gnu.org; Tue, 26 Mar 2013 16:44:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKaj0-00072Z-3t for guile-devel@gnu.org; Tue, 26 Mar 2013 16:44:08 -0400 Original-Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:45918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKaiz-00071W-OA for guile-devel@gnu.org; Tue, 26 Mar 2013 16:44:06 -0400 Original-Received: by mail-la0-f44.google.com with SMTP id eb20so14484367lab.17 for ; Tue, 26 Mar 2013 13:44:04 -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=FTYMdwHUzoREFPtfMVpfnBX8HJITEb/bLWw1CcL5Ag0=; b=fgQ/9QD6Jloggf/V/PHRVy7pSXsOnQPdVqbNR8aMKfBBFPsLL5kgcp18wncVjS/tHC U8yDpKtc2yUEM6utB90oGmKksC0TDJm3qv+Rv3lv3Tls3HRDjITYLZrEXte6Mx93Rvp/ 3tCX8t8fZmkxMNLT6YuGrNkuwzVF/H6gDdNtm54iEVsqmZa9dh6a+xWpJvnA2HLHmxh4 devme4TF4vl878s68ed6n9sqmQOfUKzJNYZiBK1DG6v20UI2aiJ/FSco5uBagdRHvZAG WByIubS7K6kO5ryEIcoj6xpZ8CvNX5Sl0XwFHFbHy087DUUgFLsiks/JCbkGtkGOstC4 CLdw== X-Received: by 10.152.109.112 with SMTP id hr16mr9093330lab.38.1364330644593; Tue, 26 Mar 2013 13:44:04 -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 kw9sm7241375lbb.4.2013.03.26.13.44.01 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 13:44:02 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; x86_64; ; ) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22c 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:16003 Archived-At: Relly kind of you to answer this quickly, good thoughts! On Tuesday, March 26, 2013 02:05:41 PM Noah Lavine wrote: > Hello, > > Two quick thoughts on this: > > 1. It's confusing to say "undo" and "redo", because those aren't in > the Scheme standard, and I don't know of any SRFIs that have them > either. Instead, maybe you could say "using continuations to > implement computations that restart". Or, "using continuations to > implement backtracking in a logic program" (if that's how guile-log > does it). Good point, I will define the wording. > 2. Can you say more about how you would implement them with parameters > and why that's not good enough? Maybe you could show equivalent code > snippets using parameters and your proposed form. parameters, and fluids are they not the basically the same? just a different interface? with parameters more flexible and fluids more optimized although parameters can be inlined many times? > 2a. If parameters work but are annoying to use, how about fluids? > Guile and a few other Schemes implement them. Maybe this could be a > justification for making fluids into a SRFI, instead of introducing a > new interface. I took them for basically the same concept. I just saw a srfi for parameters thought I should use them instead. I will try read the spec for fluids and parameters again. > 3. Points number 8 and 11 have no text at all, just code. It's not > clear what they mean. I will add text to this, good point. > 4. In general, I think this proposal is too low-level. You shouldn't > require people to implement it in a certain way; you just want to > convince them that it's *possible* to implement this reasonably. Please note that that in the semantics I mention for example integer numbers just to be precise. I do not expect people to use the code exactly as I write it. I do expect the implementors to optimize away quite a lot of what the spec describes e.g. I'm not describing a macro I'm describing an algorithm in for that case I believe to be pretty exact. The tail call properties is quite important for practiaclly be able to share logic programming using this srfi without it I fear that portability will only be on paper. > Overall, I think I would organize this into three sections: > > I. Examples showing the need for a new type of variable. > II. An exact specification of the semantics of these variables. I > gave a partial specification by rewriting special variables as > lexicals and using continuation-passing style in a previous email. I > think that would give the semantics that you want, and I can help > with that if you'd like. III. An example implementation. This doesn't > have to be the implementation that would really be used; it just > needs to be enough to show that it is possible to implement this in a > reasonable way. Good idea. btw I do have a implementation already that I can copy in. But not all logic can be coded without actually changing the compiler. Also I would add a discussion about optimisations to show that one would gain in speed and e.g. show that the argument for speed improvement is sound. Finally a discussion about ease of implementation could be good to show that we can get far by piggypacking on current technology and what things in the spec might cause the most trubble e.g. the dynamic condition that guarantees tail call property. I have an issue with continuation passing style and you point it out as well in your email. Special variables placed in a lambda would cause trouble with this approach and not only this I would like to try let the construct guard toplevel variables as well and hence these (horably) could change when someone reinstates a continuation. I do see the beuty of your approach and it describes and important optimisation that quite ofthen will apply, actually there is bloat using the guard and if you litter the code with guarding yoe relly want this type of behavior most of the time. Thanks Stefan