From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Special variables to relax boxing Date: Thu, 21 Mar 2013 02:00:29 -0400 Message-ID: <87wqt19ts2.fsf@tines.lan> References: <3101921.Ei70kTLzB2@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363845653 31449 80.91.229.3 (21 Mar 2013 06:00:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2013 06:00:53 +0000 (UTC) Cc: guile-devel@gnu.org To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 21 07:01:16 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 1UIYYt-0004UA-6P for guile-devel@m.gmane.org; Thu, 21 Mar 2013 07:01:15 +0100 Original-Received: from localhost ([::1]:55542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIYYV-00085c-Di for guile-devel@m.gmane.org; Thu, 21 Mar 2013 02:00:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIYYP-00085L-Fq for guile-devel@gnu.org; Thu, 21 Mar 2013 02:00:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIYYO-0000k6-CC for guile-devel@gnu.org; Thu, 21 Mar 2013 02:00:45 -0400 Original-Received: from world.peace.net ([96.39.62.75]:43789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIYYO-0000if-7W for guile-devel@gnu.org; Thu, 21 Mar 2013 02:00:44 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UIYYH-00025q-4U; Thu, 21 Mar 2013 02:00:37 -0400 In-Reply-To: <3101921.Ei70kTLzB2@warperdoze> (Stefan Israelsson Tampe's message of "Tue, 19 Mar 2013 23:05:52 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15944 Archived-At: 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