From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] primitive resolution for public refs Date: Mon, 12 Mar 2012 15:42:01 -0400 Message-ID: References: <87haxt3h53.fsf@olor.terpri.org> <87aa3l3det.fsf@olor.terpri.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1331581366 14076 80.91.229.3 (12 Mar 2012 19:42:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2012 19:42:46 +0000 (UTC) Cc: guile-devel@gnu.org To: BT Templeton Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 12 20:42:45 2012 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 1S7B8m-0000wy-Tk for guile-devel@m.gmane.org; Mon, 12 Mar 2012 20:42:45 +0100 Original-Received: from localhost ([::1]:50903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7B8m-0007li-A3 for guile-devel@m.gmane.org; Mon, 12 Mar 2012 15:42:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7B8X-00073d-0n for guile-devel@gnu.org; Mon, 12 Mar 2012 15:42:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7B87-00048W-Gu for guile-devel@gnu.org; Mon, 12 Mar 2012 15:42:28 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:44868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7B87-00048G-9u for guile-devel@gnu.org; Mon, 12 Mar 2012 15:42:03 -0400 Original-Received: by iajr24 with SMTP id r24so8236094iaj.0 for ; Mon, 12 Mar 2012 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8/E26M5o3ScOlSZS9niq5dIEG4ddCj5Cwlbq91cUZAM=; b=rB+f7M2opeTdcSocvFkY21TAtPpSh41rA45D+vC38MgQVvwFK4jb41dxG72ofQxiES ypGwZVES+CNkLQRHfmO75ESMo3OW4zDYyNwaeDjaL3RkSA1zm1UKkY4NkQtrxCPoIwZx u4Nl9hXEoVfOYUGmLRpscjUIAJCOO9osDUQ1mrne58KnoxfpsZ61aoNzx879Iv0cvZNk VrD10z/DjoOh11Klf6hLz7NwPwYlvmQ7yjGx12W3VhFwFF4wsDJ7+e9PE/dSszl9GMPa OPGX5wljNthxZ6PMe/LGziNH/AWHNlTOIM0Pp5WhY9xt3mNuxSgJk3CBdTeS8JY2Ooee wZlA== Original-Received: by 10.50.51.162 with SMTP id l2mr323039igo.61.1331581321195; Mon, 12 Mar 2012 12:42:01 -0700 (PDT) Original-Received: by 10.42.218.69 with HTTP; Mon, 12 Mar 2012 12:42:01 -0700 (PDT) In-Reply-To: <87aa3l3det.fsf@olor.terpri.org> X-Google-Sender-Auth: qxzrJ43_MsWCNF8wzvgLfe_hKhU X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.169 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:14090 Archived-At: Hello, > I don't think I've changed the correctness wrt `module-set!' and the > like -- the current, private-refs-only optimization already exhibits the > problem you describe: > > | scheme@(guile-user)> (define old-car car) > | scheme@(guile-user)> (module-set! (current-module) I think (current-module) should be (guile) here. Otherwise I think you will change 'car in (guile-user) and not affect (guile). But I have no doubt that this bug is real. > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'ca= r > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (la= mbda (x) (format #t "car ~A~%" x) (old-car x))) > | scheme@(guile-user)> ,x (lambda (x) ((@@ (guile) car) x)) > | [...] > | Disassembly of #:4:0 (x)>: > | > | =A0 0 =A0 =A0(assert-nargs-ee/locals 1) =A0 =A0 =A0;; 1 arg, 0 locals > | =A0 2 =A0 =A0(local-ref 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;; `x' > | =A0 4 =A0 =A0(car) > | =A0 5 =A0 =A0(return) > > I'm not certain it's otherwise correct; I just added a workaround for > the specific issue mentioned in the comment. Yes, you're right. That just raises the question, though: what's the right thing to do? I realized that you could argue this is part of making a closure, because it closes over the current value of variables in other modules. That doesn't match the behavior of regular closures, though: they just close over storage locations, so they can still be affected by external set!'s. Noah