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: Wed, 27 Mar 2013 08:13:46 +0100 Message-ID: <5150614.XCd6n4rqTv@warperdoze> References: <13378334.Jv25yq6OaM@warperdoze> <1767639.rWRbQJn65G@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 1364368437 11427 80.91.229.3 (27 Mar 2013 07:13:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 07:13:57 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 08:14:23 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 1UKkYu-0002Xu-Vn for guile-devel@m.gmane.org; Wed, 27 Mar 2013 08:14:21 +0100 Original-Received: from localhost ([::1]:60937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKkYW-00006I-Ra for guile-devel@m.gmane.org; Wed, 27 Mar 2013 03:13:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKkYS-00005x-9V for guile-devel@gnu.org; Wed, 27 Mar 2013 03:13:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKkYR-0004LD-89 for guile-devel@gnu.org; Wed, 27 Mar 2013 03:13:52 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:41817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKkYR-0004Kv-0t for guile-devel@gnu.org; Wed, 27 Mar 2013 03:13:51 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id fr10so15144629lab.12 for ; Wed, 27 Mar 2013 00:13:50 -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=u6M1J2By5uhso/Q43aWp9S1KnqrwXzADP2KUPvKjKyQ=; b=GDxg24flUUmBjaB6guIWGkcoSkiDBqNJEcTvp9KkVxvcMg5TBVyci3JCz9gaRR7GFH 9OB9WtTtdMjgyi7Z1kZ6Lo0/xdUVMeAi7dfu8MYL2NW6WyKnZaAn56Z9e6otZ6td9MnY gjUgkFz/ClFZ2+niVOwuwnT6MixGLtTtjGAiTr1eMElDscWCglID4b0UhvxA69gFsuvw h+VaXqEi7C8xZUhHzAOYRm7Cg0WKzupcglKOH8fJOKXm3u2RdwTGk28uX9qe2uPtoMVd TR/G2rj0MCgq9S7ddhUUxddIJrZVVp/nvT5gx2SIZjHUZK0T7MWtq3XiwmLCnBnslXfI 44Mw== X-Received: by 10.112.100.103 with SMTP id ex7mr9540439lbb.80.1364368430104; Wed, 27 Mar 2013 00:13:50 -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 o11sm7760357lbu.6.2013.03.27.00.13.47 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 00:13:48 -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::235 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:16016 Archived-At: On Tuesday, March 26, 2013 06:36:46 PM Noah Lavine wrote: > Okay. I don't see a use for number 1. Could you explain why it's > important? It seems easier to me to just let each variable have its > own type. Actually it has it's uses. 1. Note. This ideom aims at being a sound extension to the case where we have non boxed local variables that are never put into a closure and where we mutate them with lexical-set directly. Maybe that is easier to think of them this way. As you see this ideom will enable pretty fast execution of the code in the common case where the variable is never put in a closure. It will in the not uncommon case when you put a local variable inside a closure and return it and preserve the redo safe property. I didn't see that fluid-let could allow this as well through an optimization e.g. (let ((a 1)) code ...) redo safe and can be well optimized => (let (a) (fluid-let ((a 1)) code ...)) And it's actually better in many ways in that fluid-let guards the outer context of the variable to be changed. On the other hand, fluid-let does not mix well with delayed computations, my suggestion does so indeed. So Different notions, different benefit. But as you say thay are close to my number 2 suggestion > As for 2, I believe that's how MIT Scheme's (fluid-let ...) works. I > suspect that if you give up property 1, then fluid-let would do the > job you want. No, parameter values are stored in different dynamic state and because you have one dynamic state per thread usually (it's possible to let threads share dynamic-state) the concpet is safe with respect to multithreading. It does not look like fluid-let have that property. a) > Also, in the example you gave earlier (in your third email in this > thread, beginning with "you need to combine fluids and dynamic wind > ..."), I don't see the difference between set! and set~ semantics. b) >It > seems like the variables there have exactly the same semantics as > fluids, except that you don't have to use (fluid-ref ...) to get > their value. a) set! means that you will box a value. The coders intention is that it should behave as such. With set~ you will many times be able to unbox the value. But as you say, with the example it may look like they are the same. But note that putting a set! in the code means that the variables becomes unguarded and the with-undo-variables becomes a no-op. Really The whole setup is done in order to keep ~ semantic enclosed in a macro and the user of the macro should can work as if the macro only uses local variables with no set!. b) As I said, you are right that they are close in notion and many times the semantic will overlap but as described above they are different. /Stefan