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: Thu, 28 Mar 2013 09:36:42 +0100 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <36877746.VlrjcRTRXD@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1364459817 14434 80.91.229.3 (28 Mar 2013 08:36:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 08:36:57 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 28 09:37: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 1UL8Kg-0000dx-G7 for guile-devel@m.gmane.org; Thu, 28 Mar 2013 09:37:14 +0100 Original-Received: from localhost ([::1]:38253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8KI-0006e6-Cv for guile-devel@m.gmane.org; Thu, 28 Mar 2013 04:36:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8KD-0006e1-5Y for guile-devel@gnu.org; Thu, 28 Mar 2013 04:36:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UL8KB-0003Rm-RR for guile-devel@gnu.org; Thu, 28 Mar 2013 04:36:45 -0400 Original-Received: from mail-da0-x22f.google.com ([2607:f8b0:400e:c00::22f]:57554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8KB-0003Rg-KA for guile-devel@gnu.org; Thu, 28 Mar 2013 04:36:43 -0400 Original-Received: by mail-da0-f47.google.com with SMTP id s35so4451163dak.34 for ; Thu, 28 Mar 2013 01:36:42 -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=1Aawst4oBv9WvSt+adOyYgYIgOsS4oJrni3xEvSplrI=; b=xR71fJZfEreBvlBQE6Mna6kUwdu7yZlsJSGnG/km/G+zL1dIsWD9ZQ9R8b1k6qnlrT zLC5e+jCMCJ20WSp5SBAm9rO59WAB1tHWkDNqgolLCM1jsraxmbRUsMc4Z25C83D7u1A vcRtAiykQ4nfVzP30B/tXLrZ+3I3kKChxKA2KUgoLHaoxNCua6hXNwIQsKOmFwh7+uLN 2eA6L94rL2gVaNb2SYOupZ11FgwLsqH4SXLTuf9/Xf0qEV+dG2PQa52MoF8lMmBzBgjl LfNk4dJQCWpSR+JgQWIPHQruZmpVeAdeNypbx07dTBiUaEA7/jJeknpTD1f72Tdmb2CS 1D7Q== X-Received: by 10.66.255.99 with SMTP id ap3mr35188345pad.102.1364459802556; Thu, 28 Mar 2013 01:36:42 -0700 (PDT) Original-Received: by 10.70.45.8 with HTTP; Thu, 28 Mar 2013 01:36:42 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c00::22f 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:16045 Archived-At: Yeah, they are different for sure, The last attempt failed though the previous one was better. The reson I have a hard time trying to code it is that In one end I wouldl like to build the spec on what's already there. And on the other hand make sure that it play well with dynamic states. The issue is that I don't want to spoil some natural optimisations due to a bad spec. The old approach meant that you alway's needed to use the expensive version of the construct and spoil much of it's simplicity in implemenetation. I will have new try, this evening. /Stefan On Wed, Mar 27, 2013 at 10:46 PM, Noah Lavine wrote: > On Wed, Mar 27, 2013 at 5:44 PM, Noah Lavine > wrote: >> >> >> Since it's definable with such a simple macro, I don't think it's >> appropriate for a SRFI. >> > > Sorry, I just realized that that's not a sensible objection. If it's a > better interface than parameters, then it certainly should be a SRFI. > However, I won't be convinced of that until I've played with both for a > while. So I would suggest waiting a bit until it's clear what the best way > to manage variables like this is. > > Noah