From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Price Newsgroups: gmane.lisp.guile.devel Subject: Re: Mutable top-level bindings Date: Wed, 17 Apr 2013 21:25:13 +0100 Message-ID: <874nf4lxau.fsf@Kagami.home> 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; charset=us-ascii X-Trace: ger.gmane.org 1366230323 2964 80.91.229.3 (17 Apr 2013 20:25:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2013 20:25:23 +0000 (UTC) Cc: "Chris K. Jester-Young" To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 17 22:25:26 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 1USYv0-0002k7-Hi for guile-devel@m.gmane.org; Wed, 17 Apr 2013 22:25:26 +0200 Original-Received: from localhost ([::1]:44576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USYv0-0007uB-2v for guile-devel@m.gmane.org; Wed, 17 Apr 2013 16:25:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USYuw-0007tn-HV for guile-devel@gnu.org; Wed, 17 Apr 2013 16:25:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USYuu-0003fr-Fv for guile-devel@gnu.org; Wed, 17 Apr 2013 16:25:22 -0400 Original-Received: from mail-wg0-f49.google.com ([74.125.82.49]:45570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USYuu-0003fO-9z for guile-devel@gnu.org; Wed, 17 Apr 2013 16:25:20 -0400 Original-Received: by mail-wg0-f49.google.com with SMTP id x12so2012245wgg.28 for ; Wed, 17 Apr 2013 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=e//I3kSHgYQ0sXrqAw2YDD4Ilyahia23stib4CjO5o0=; b=kYSDHsr2lBGMsnjjLURiSX5VIXEsXcQV2aNPNF2SRCkvUWwhIUvf9Kmr9w4OmR7Vcz yLRKOAq/5Y50hOSwflocLATI07Sq3LkikqUmzLzrNqg/RM9va0Act079OejakOEHAFuO DB6mLR+tcaExp7RK8ci7xFNZ58b8B1kCBZbggP+M1nSblDOFpKH8TqdYeWye4e44YuTv iq74/W+ERF8I0A22Zff3+dHhRPxxgw/Rkumn6gRjz1ejpfZ2oPqvAnGVgoeeMLlw9oD4 UaJVoPZsArJna5A0IrK/fsCjfF5cJG0cKavzZ0MRlTfGYdw8OS+Zulde8sV4v0bLHuUP hldA== X-Received: by 10.194.176.195 with SMTP id ck3mr14081171wjc.5.1366230319068; Wed, 17 Apr 2013 13:25:19 -0700 (PDT) Original-Received: from Kagami.home (host81-155-24-234.range81-155.btcentralplus.com. [81.155.24.234]) by mx.google.com with ESMTPS id ej8sm27661373wib.9.2013.04.17.13.25.16 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 17 Apr 2013 13:25:17 -0700 (PDT) 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/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.82.49 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:16270 Archived-At: "Chris K. Jester-Young" writes: > With a proper module system, I don't see why top-level bindings should > be mutable. 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. Not top-level, but _exports_ and _imports_. While their use is often ugly, I'm not sure we should do away with all top level mutables. Since I write a lot of R6RS code, I'm pretty used to the "no mutable exports/imports" deal. It isn't too bothersome, except in some cases with macros and so-called implicit exports/imports. (see bottom) > Yes, this does disable the ability to perform monkey-patching. I don't > see this as a big loss, but perhaps there are legitimate use cases for > monkey-patching that I haven't thought of. It is pretty useful to be able to do redefinition in a different module at the repl. Perhaps I could come up with a tortured argument to explain why this is different from mutating a top-level export, but I'll refrain :) > 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))) +1 > This would obviate the need to use the following pattern: > > (define foo #f) > (define bar #f) > (define baz #f) > (letrec ((my-foo ...) > (my-bar ...) > (my-baz ...)) > (set! foo my-foo) > (set! bar my-bar) > (set! baz my-baz)) This example is one that does not work in R6RS if you export foo, bar, or baz. To do this, you need an additional set of defines that indirect to the mutated ones. e.g. https://github.com/rotty/spells/blob/master/spells/define-values.sls > > Granted, there are existing modules that use that approach currently, as > we don't currently have define-values. But I think it should be possible > to annotate individual modules as having immutable top-level bindings, > so that we can gradually migrate modules to the define-values style. > * Implicit imports/exports (http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1) "An exported macro may, however, implicitly export an otherwise unexported identifier defined within or imported into the library. That is, it may insert a reference to that identifier into the output code it produces." "All implicitly exported variables are also immutable in both the exporting and importing libraries. It is thus a syntax violation if a variable appears on the left-hand side of a set! expression in any code produced by an exported macro outside of the library in which the variable is defined...." -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"