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: Special variables to relax boxing Date: Thu, 21 Mar 2013 10:35:44 +0100 Message-ID: References: <3101921.Ei70kTLzB2@warperdoze> <87wqt19ts2.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1363858561 13797 80.91.229.3 (21 Mar 2013 09:36:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2013 09:36:01 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 21 10:36:24 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 1UIbv6-0005nm-6l for guile-devel@m.gmane.org; Thu, 21 Mar 2013 10:36:24 +0100 Original-Received: from localhost ([::1]:42218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIbui-00051H-VL for guile-devel@m.gmane.org; Thu, 21 Mar 2013 05:36:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIbua-00050J-KO for guile-devel@gnu.org; Thu, 21 Mar 2013 05:35:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIbuV-0007BU-2t for guile-devel@gnu.org; Thu, 21 Mar 2013 05:35:52 -0400 Original-Received: from mail-pb0-f50.google.com ([209.85.160.50]:62253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIbuU-0007An-2H for guile-devel@gnu.org; Thu, 21 Mar 2013 05:35:46 -0400 Original-Received: by mail-pb0-f50.google.com with SMTP id up1so2099939pbc.37 for ; Thu, 21 Mar 2013 02:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=urVgR+7aoSdMHUtCzwDuEqhc4t4ckyR8c+OMPs/5hc4=; b=MtkWXM4QJkCaN7gvseBVghrL6Nfqrg0m/ihigggkbrCXj1OSWEusaHEO7kX0FCfG+z efn+fKw5f+gLE4HSeM2zVqri/y16YD9+FrmCM6cmZGivZCYK/Tqm3CeQEZi4Mq2ysh2m EZ9gFTYAXdDbiPGbJ6E2Wy20k1jVAK/hZk3e++4ezq0nctTFzHwXGAASodHFDYRW/ebo ZFGn2dx7YkMTjHP0rsgf2RgZUAimLk0U4W7mNB1/ddrdVXhtwidGQ3EU4nLBYp3wkP5t IVIsfNxJh341sYTwb903Om47RiVK5rrbwM5MAKlra9qe419NLrAzcehe26XEyk3cL99n j4AQ== X-Received: by 10.68.27.164 with SMTP id u4mr3526345pbg.69.1363858544613; Thu, 21 Mar 2013 02:35:44 -0700 (PDT) Original-Received: by 10.70.45.8 with HTTP; Thu, 21 Mar 2013 02:35:44 -0700 (PDT) In-Reply-To: <87wqt19ts2.fsf@tines.lan> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.50 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:15947 Archived-At: Ok, This was a first step to get what I would like to have implemented in the tree il backend (Not for scheme but perhaps something useful for e.g. emacs-lisp, python etc). My main issue with the current setup is that adding undoing and redoing feature with the help of prompts will fail in 95% of the cases where the program is written in an imperative style which is not uncommmon in languages we would like to support in guile. Prompts is such a cool feature and is probably one of the main selling points of why one should use their language ontop of guile. So I've just exploring how to improve on this. I think you missundeerstood my posted semantic. It will box if you set! a variable and the same variable is located in a closure, I think that is a safe approach. But you are right that it's a very unclear semantic but my intention was to use this as a step of a better primitive. So over to the semantic I would like to have, To do it currently in guile you would need to do something like, (define-syntax with-guarded-var (lambda (x) (syntax-case x () ((_ var code) (with-syntax ((guard ...)) #'(let ((guard (make-fluid))) (with-fluids ((guard var)) (dynamic-wind (lambda () (set! var (fluid-ref guard)) (lambda () (mark-as-special var) code) (lambda x (fluid-set! guard var))))))))))) It might be improved but is really really a horrendous solution to the semantic. The semantic is pretty close to a fluid variable solution but it will mix much better with delayed computations and is a big reason for not using fluids in a more simple try. What I would like to propose is an idiom in tree-il that basicly looks like (with-special (var ...) code ...) and what it does is to put onto the stack is the following ---------------------------- mark var1 place1 var2 place2 ... mark-end ----------------------------- and then execute the code just as nothing have happend. Then we could add the code to the stack copying part of the prompt cal/cc etc to when scanning the stack backwards, if it sees maek-end, then it will store the value of var1 in place 1 etc. And when reinstalling the stack it will search for the mark and place the value of place1 into the var in var1 and so on. Another solution is to add a new control ideom onto the control stack where the fluid controls and dynamic wind control lives with a pointer ti the var1 position and the number of vars. With this solution we can skip the marks and also improve the performance of the installment and savings of the stack, the drawback is that we neede to handle that we install the saved stack perhaps at another adress, but it's doable. (A good thing using this is that we can reuse this rebasing technique to improve the speed and scaleup of fluid variables at a tail call position in many cases) I actually use a clumsy version of this semantic in guile-log and I know that although it is anesoteric feature it means that you can easilly implement really cool features that I would not dare to write in e.g. kanren, If you write a prompt based logic implementation It will make a hughe difference in what you have the above semantic without going down to snail speed. To increase speed further the system would use (mark-as-special) and check if it can be unboxed, in which case tha variable will not be baxed and with-special will be a no op. I hope that this is a clearer description of what I'm aiming at! /Stefan On Thu, Mar 21, 2013 at 7:00 AM, Mark H Weaver wrote: > Hi Stefan, > > Stefan Israelsson Tampe writes: >> I wouldl like to start a discussion of introducing a way to mark >> variables as special, and by that mean that set! variables does not >> nessesary get boxed. > > I don't think you fully understand the ramifications of what you're > proposing here. In the general case, mutable variables need to be boxed > because closures end up with copies of any free variables that they > reference. If a free variable is mutable, that means it needs a copy of > the _location_ where the value is stored. Making a copy of the _value_ > of a variable at the time of closure creation would lead to very > unintuitive (and IMO broken) behavior. > > More importantly, you are describing this proposed language feature in > terms of low-level implementation details. If you're serious about > proposing such a fundamental new feature to Scheme, please start by > reading and understanding the denotational semantics of the R5RS, > especially sections 3.1 and 3.4, and then reformulate your proposal in > those terms. For such a fundamental change, I'd want to see a proposed > new formal denotational semantics to replace those in section 7.2. > > To be honest, I'm not suggesting this to help you refine this proposal. > I'm suggesting it because I think it would help you to think more > clearly about these issues, and to appreciate the beautiful elegance of > Scheme's minimalist semantics. Furthermore, I hope it would help you to > understand what a terrible mistake it would be to muck such a beautiful > language with hacks such as this. Every added bit of complexity in the > core of a language has to be paid for a hundred times over, in both code > (compilers, optimizers, etc) and more importantly in the mental effort > required to reason about the language. > > Mark