From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Marijn Schouten (hkBst)" Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Thu, 23 Jul 2009 17:24:30 +0200 Message-ID: <4A6880AE.9070600@gentoo.org> References: <4A661B73.4090706@domob.eu> <4A66D7BF.5060606@domob.eu> <4A670D78.3040804@gentoo.org> <4A67676F.9010905@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248363252 28447 80.91.229.12 (23 Jul 2009 15:34:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 15:34:12 +0000 (UTC) Cc: Andy Wingo , Ken Raeburn , guile-devel , Neil Jerram To: Daniel Kraft Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jul 23 17:34:05 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MU0J2-0004wP-Je for guile-devel@m.gmane.org; Thu, 23 Jul 2009 17:34:04 +0200 Original-Received: from localhost ([127.0.0.1]:34206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU0J2-0006vA-2i for guile-devel@m.gmane.org; Thu, 23 Jul 2009 11:34:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU0Iu-0006u2-Vk for guile-devel@gnu.org; Thu, 23 Jul 2009 11:33:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU0Iq-0006kf-7r for guile-devel@gnu.org; Thu, 23 Jul 2009 11:33:56 -0400 Original-Received: from [199.232.76.173] (port=40662 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU0Ip-0006kP-VV for guile-devel@gnu.org; Thu, 23 Jul 2009 11:33:51 -0400 Original-Received: from castor.sshunet.nl ([145.97.192.41]:57673) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MU0Ip-0007Wg-EI for guile-devel@gnu.org; Thu, 23 Jul 2009 11:33:51 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by castor.sshunet.nl (Postfix) with ESMTP id 489A957C03C; Thu, 23 Jul 2009 17:33:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at castor.sshunet.nl Original-Received: from castor.sshunet.nl ([127.0.0.1]) by localhost (castor.sshunet.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxhqc0J0mevX; Thu, 23 Jul 2009 17:33:49 +0200 (CEST) Original-Received: from [145.97.223.81] (81pc223.sshunet.nl [145.97.223.81]) by castor.sshunet.nl (Postfix) with ESMTP; Thu, 23 Jul 2009 17:33:49 +0200 (CEST) User-Agent: Thunderbird 2.0.0.22 (X11/20090630) In-Reply-To: <4A67676F.9010905@domob.eu> X-Enigmail-Version: 0.95.7 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8922 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Kraft wrote: > Hi Marijn, > > Marijn Schouten (hkBst) wrote: >> Guile also has lexical and dynamic variables; the fluids[1]. Queinnec >> in his >> book LiSP also describes a system that has (default) lexical and dynamic >> variable, on page 44. In both cases to find the value of a non-default >> variable >> a function is used. Translated to elisp where the situation is dynamic by >> default you probably want something like `(lexical x)' to dereference the >> lexical variable `x' and also lexical-set(q). >> >> It seems to me that only the dereferencing of variables is dynamic or >> lexical, >> not the binding. Thus you don't even need lexical-let and `(lexical >> x)' would be >> `x' found in the lexical environment (if it isn't found you can >> generate an >> error) and `x' would be searched for in the dynamic environment. Does >> that make >> sense? > > not only the dereferencing, but also the setting must be of a dynamic or > lexical value; yes and one could argue that to set a variable you need to dereference it first too or you won't know which location you're set'ting. > and at least in my Lisp code, setting is mostly done with > let's, so at the same time as the "binding". Unless elisp is the exception, let does not set any variables, but only introduces bindings. > So what you propose would then be to have a (lexical sym) for > referencing and (lexical-set! sym value) for setting in lexical scope -- yes. > and then as a consequence also a lexical-let, that does let but sets to > the provided values just as lexical-set! does...? Well, that's how I > see it, anyways. no, let does no assignement AFAIK. > And while your arguments seem quite reasonable (decide for each access > of a symbol between lexical and dynamic), I think this creates a > superfluous amount of confusion and "just" switching for certain > variables to lexical binding within the scope of a lexical-let seems to > me the better solution. Aha, now I understand what you want lexical-let to mean. If you are explicit about each variable access how can that be confusing? Possibly confusing is if you have to examine the complete enclosing context for lexical-let's. > What's about this: > > (defun test () a) > (let ((a 1)) > (print a) ; 1 > (print (test)) ; 1 > (lexical-set! a 2) there is only one variable `a' in my mental model, so this changes the value of the only `a' and all subsequent expressions accessing `a' are thus affected. The same as if you had written `(set! a 2)'. Dynamic and lexical only differ in how free variables in procedures are bound. > (print a) ; 1? no, (print a) => 2 > (print (test)) ; 1 no, there is only one `a' and its value is 2 here > (print (lexical a)) ; 2 > ) > > I don't think it's good to have to "completely seperate" variables a and > (lexical a). I don't understand what you mean. My proposal is to have one kind of variable and two kinds of access. > And besides, here there's no way to decide that no fluids > at all are needed for a, as the let construct itself (except the > references following) still creates a with-fluids* call. For the calls above all the dynamic accesses can be determined statically. Lexical accesses can always be determined statically. Thus all accesses in this example can be determined statically and can be compiled to a location dereference (either read or write). Nothing in the semantics is inherently inefficient. Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML , #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpogK0ACgkQp/VmCx0OL2x4JACgwYR+48aAHTjMu1S6H7Dw4utR YzoAn3hMwhEadhlrAw7a06gWZBEoDWQX =DkN6 -----END PGP SIGNATURE-----