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: Mutable top-level bindings Date: Wed, 17 Apr 2013 13:53:53 -0400 Message-ID: <878v4hdowe.fsf@tines.lan> References: <9D053760-46BC-46F1-B84D-07902E777FF2@bluewin.ch> <87haj72q08.fsf@tines.lan> <20130417152753.GA13533@lotus.destinee.acro.gen.nz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1366221267 31659 80.91.229.3 (17 Apr 2013 17:54:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2013 17:54:27 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 17 19:54:31 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 1USWYv-0006Cf-JF for guile-devel@m.gmane.org; Wed, 17 Apr 2013 19:54:29 +0200 Original-Received: from localhost ([::1]:47089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USWYv-0000Me-7z for guile-devel@m.gmane.org; Wed, 17 Apr 2013 13:54:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USWYp-0000MD-15 for guile-devel@gnu.org; Wed, 17 Apr 2013 13:54:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USWYl-0007Yx-2e for guile-devel@gnu.org; Wed, 17 Apr 2013 13:54:22 -0400 Original-Received: from world.peace.net ([96.39.62.75]:47362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USWYk-0007VR-Tu for guile-devel@gnu.org; Wed, 17 Apr 2013 13:54:18 -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 1USWYS-0002aR-M3; Wed, 17 Apr 2013 13:54:00 -0400 In-Reply-To: <20130417152753.GA13533@lotus.destinee.acro.gen.nz> (Chris K. Jester-Young's message of "Wed, 17 Apr 2013 11:29:11 -0400") 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:16269 Archived-At: Hi Chris, "Chris K. Jester-Young" writes: > On Mon, Apr 15, 2013 at 10:00:55PM -0400, Mark H Weaver wrote: >> Unfortunately, this is rarely possible in a language like Scheme, where >> calls to procedures bound by mutable top-level variables are frequent. >> We cannot fix this without making most commonly-used top-level bindings >> immutable. Last I checked, there was strong resistance to this idea. > > Maybe it's time to reopen this (and hope it's not a can of worms). :-) > > With a proper module system, I don't see why top-level bindings should > be mutable. Well, if top-level bindings are immutable, then you have to restart the system, and possibly even recompile .go files that incorporated assumptions about the immutable bindings, in order to change a binding. This is quite contrary to the Lisp and Scheme tradition of course. My preference would be to provide a way to mark bindings as "rarely mutated", such that the compiler could treat them as immutable. The binding could still be mutated, but mutation would be very expensive: it would cause all compiled code that incorporated assumptions about that binding to be immediately invalidated. This is hard to implement, though, because it requires "on stack replacement". > That would make even things like direct inlining of cons or > + somewhat harder than it needs to be. The way I understand it, the > definition of (@ (guile) cons) or the like should not be subject to > change at runtime. If people want to change the behaviour of cons, write > a module that replaces the top-level binding. Currently, our compiler treats several bindings in (guile) such as '+', 'car', 'cdr', 'cons', 'eq?', etc, as if they were immutable. See (language tree-il primitives) for the full list. However, it's not handled very well: you are still allowed to mutate those bindings, and I guess the evaluator will pick up the changes but the compiler won't. > Another thing we will need to provide is define-values, which allows you > to make top-level bindings that are mutually-recursive. By which I mean: > > (define-values (foo bar baz) > (letrec ((foo ...) > (bar ...) > (baz ...)) > (values foo bar baz))) Yes. I started work on this quite a while ago, but got distracted. Doing the job right requires changes to the "fixing-letrec" pass of the compiler. I started by reimplementing the improved "fixing letrec reloaded" algorithm (with some fixes), but for various reasons it's not yet ready for publication. The next step is to finish that work and to extend it to handle letrec-values and letrec*-values. Regards, Mark