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: Sat, 23 Mar 2013 11:30:51 +0100 Message-ID: <27839484.AINm83DS6r@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 1364034666 26246 80.91.229.3 (23 Mar 2013 10:31:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Mar 2013 10:31:06 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 23 11:31:33 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 1UJLjX-0005Aw-Ky for guile-devel@m.gmane.org; Sat, 23 Mar 2013 11:31:31 +0100 Original-Received: from localhost ([::1]:57411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJLj9-0005D2-Vj for guile-devel@m.gmane.org; Sat, 23 Mar 2013 06:31:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJLj6-0005Cx-FF for guile-devel@gnu.org; Sat, 23 Mar 2013 06:31:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJLj3-0001OP-F3 for guile-devel@gnu.org; Sat, 23 Mar 2013 06:31:04 -0400 Original-Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:52718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJLj3-0001My-87 for guile-devel@gnu.org; Sat, 23 Mar 2013 06:31:01 -0400 Original-Received: by mail-la0-f51.google.com with SMTP id fo13so8804354lab.10 for ; Sat, 23 Mar 2013 03:30:59 -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=IaKzfQTAlqnYLvIwYPVVZebIzi0BZsluOn2zZ5AWrwc=; b=Nr/wMmhDoJ7X1/J5POTkMWPcDkBTnC9Gl9Vc8mdpywWW3JVLzOhPmGfyJ6SXyzedlJ Uv+6cEITZEAoW5XEK1LwXVhCDYmEbTzeu+GLxyeOFYe3qBldNkiWdiEGHDPXCxsfIu0l EWVtzqeE9WoG8+TOThc/jxZ4WT45lfSFA3o41p4oFS0CK8vyHNigjT99acgMNq4T4BBr vP8yOquLVzy8f129/9GdHCqmawZV1oXZEBmpXfUCinfU89Y3nGUmSK7gdkohMZN29AjP 8UYr72Iv4HGRUYprc8nFzeMna9TelU2mH1Xn8+g94F0pRzSTjftyGKghkdkJ5ggOpl95 hW7Q== X-Received: by 10.112.43.232 with SMTP id z8mr2648136lbl.135.1364034659694; Sat, 23 Mar 2013 03:30:59 -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 m1sm2165562lbh.5.2013.03.23.03.30.57 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 03:30:58 -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: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::233 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:15974 Archived-At: Hi guiler, Hi Daniel. I lost this thread in my mail application, sorry, so I try to continue this way instead. * This feature for scheme is mainly for macro writers which knows what they are doing and which only guard state varibles not seen to the application programmer. This is how I use this feature in guile-log so it will not change how most people need to reason about scheme, the beuty remains. It makes insanly difficult tasks possible and simple things works as before. * I really like guile to cater for advanced users. Not only noobs. Although we should hide this feature really deep and put some serious warnings in the documentatin about the use. I actually hate using set! and if you look at e.g. guile-syntax-parse you will see that I rewrote everything with let loops, e.g. I really prefere that way of looping. I do understand your worry to let people loose on writing set! heavy code - that is not scheme. I also ported common lisp code to scheme and It was a horrible experience to see all set! ing in the code and I just had to rewrite quite a lot of the common lisp with rewriting the loops. But then a new version comes out and you are smoked. * If we are serious about combining emacs-lisp with guile we should really aim to have this feature added with deep support. The reason is that using set! in lisp world is a style of programming and is very common. For this reason I don't expect much emacs-lisp to combine well with undo redo additions via prompts. This hearts me really hard because it would be so cool to be able and schime in to a emacs-lisp project, add a few lines of code and show of a well functioning redo and undo addition to the complex emacs lisp code - this would be a really good selling point for guile-emacs and as I said, I hate that we don't have a nice support for it. * The proposed semantics piggy packs ontop of fluids sematics so everything we have done incorporating fluids carry over directly to special variables. And the extra stuff is really not that much. E.g. the maintainance burden is probably much less that your perception of it. * We need 2 extra VM op's if we are serious ablut implementing this though but they are simply essentially a copy paste of the fluid code so one could factor out the code somewhat. Another possibility is to add an option to the current fluid vm ops. * If you don't redo and undo nothing in the way scheme works changes it's only when you undo and redo stuff that the semantics becomes important. I really think that this is an important addition of guile and it would really be a dissapointment not having it's support considering the great gain you can get via optimizations with really not much extra work in guile. Also I think that I managed to get the semantics and implementation in a really beutiful state where a lot of effort have been in making it mix well and be consistant in what it does and actually get it into a state where it _is_ much simpler to reason about the code considering other way's of implementing the optimisations. Albait more difficult than before. Have fun /Stefan