From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Chris K. Jester-Young" Newsgroups: gmane.lisp.guile.devel Subject: Mutable top-level bindings (was: vectors are something else) Date: Wed, 17 Apr 2013 11:29:11 -0400 Message-ID: <20130417152753.GA13533@lotus.destinee.acro.gen.nz> References: <9D053760-46BC-46F1-B84D-07902E777FF2@bluewin.ch> <87haj72q08.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366212594 26734 80.91.229.3 (17 Apr 2013 15:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2013 15:29:54 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 17 17:29:56 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 1USUIx-0004y5-Pt for guile-devel@m.gmane.org; Wed, 17 Apr 2013 17:29:51 +0200 Original-Received: from localhost ([::1]:44868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USUIx-0007RD-4h for guile-devel@m.gmane.org; Wed, 17 Apr 2013 11:29:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USUIs-0007R6-IH for guile-devel@gnu.org; Wed, 17 Apr 2013 11:29:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USUIq-0002cT-KR for guile-devel@gnu.org; Wed, 17 Apr 2013 11:29:46 -0400 Original-Received: from mail-qe0-f47.google.com ([209.85.128.47]:33381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USUIq-0002al-Gm for guile-devel@gnu.org; Wed, 17 Apr 2013 11:29:44 -0400 Original-Received: by mail-qe0-f47.google.com with SMTP id w7so947954qeb.20 for ; Wed, 17 Apr 2013 08:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=jST1QFZ4d6B6Jvj1m7jYHN619sIU1NOWF/rXA+l4ERQ=; b=rO5NtoYg8CKDFh28foJ9wz0WkrbyZUFYpLyp+8gQZvS9P2PGCO2lj9IZe8VWhPZGcH p3PkPlSkKLYhKwE8Wr78qFMd+ZTFn/zWGvkuygDMW5NxmNJXIG9p0w3a7BKLlhuIyJhv xvGSHEuZLT2Eps0NfJG4KT0vPf+AHE92g2QPMJrHboOvfC+gjg4hbozt7lTlOZ7QeKio QgvYC2H6YsWDxHpHZDl7zqr7ooMa1V1hsl9iPWPVZFUeFyvxJ0+o0Jjau2srHd77CqUn xhb5nhv/w8yp/kmBN6+JODlDvVHIEwfPDs65+krOLf8Fj7Bj4QQgldAxP1rrIMLnsFUa mFLA== X-Received: by 10.49.128.33 with SMTP id nl1mr7690893qeb.45.1366212583449; Wed, 17 Apr 2013 08:29:43 -0700 (PDT) Original-Received: from lotus.destinee.acro.gen.nz (cpe-107-015-120-110.nc.res.rr.com. [107.15.120.110]) by mx.google.com with ESMTPS id kf2sm6902950qeb.4.2013.04.17.08.29.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Apr 2013 08:29:42 -0700 (PDT) Mail-Followup-To: guile-devel@gnu.org Content-Disposition: inline In-Reply-To: <87haj72q08.fsf@tines.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.128.47 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:16267 Archived-At: 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. 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. 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. 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))) 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)) 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. Cheers, Chris.