From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kent M Pitman Newsgroups: gmane.emacs.help Subject: Re: Differences between Elisp and Lisp Date: 29 Apr 2003 12:44:22 -0400 Organization: My ISP can pay me if they want an ad here. Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <3eae89b4$0$13158$3b214f66@usenet.univie.ac.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1051634875 12677 80.91.224.249 (29 Apr 2003 16:47:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2003 16:47:55 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 29 18:47:52 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19AYGP-0003Fj-00 for ; Tue, 29 Apr 2003 18:47:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19AYFH-0003Lq-07 for gnu-help-gnu-emacs@m.gmane.org; Tue, 29 Apr 2003 12:46:19 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!petbe.visi.com!uunet!ash.uu.net!dca.uu.net!nntp.TheWorld.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 76 Original-NNTP-Posting-Host: shell01.theworld.com Original-X-Trace: pcls4.std.com 1051634662 19570 199.172.62.241 (29 Apr 2003 16:44:22 GMT) Original-X-Complaints-To: abuse@TheWorld.com Original-NNTP-Posting-Date: Tue, 29 Apr 2003 16:44:22 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-Xref: shelby.stanford.edu gnu.emacs.help:112524 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:9021 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:9021 Phillip Lord writes: > >>>>> "Kent" == Kent M Pitman writes: > > Kent> Thomas Link writes: > > >> > I thought that CL already implemented lexical binding? At least > >> >within a let form (or "lexical-let"). > >> I guess it's faking lexical binding by replacing variable names > >> with gensyms. This makes it pseudo-lexical but not more > >> efficient. > > Kent> In addition to having questionable efficiency issues, such a > Kent> strategy also eliminates the one primary reason that more than > Kent> anything justifies lexical scoping--the ability to know 'just > Kent> by looking' that no other uses of the variable exist and that > Kent> it's ok to optimize. > > Perhaps I am confusing things here, but I always assumed that the > problem with dynamic binding is that it makes odd things happen. You're saying the same thing as I was saying only in different words. Both the efficiency loss and this other effect you cite (accessibility from outside) are effects of having the name be accessible from the outside. In general, both a programmer and a compiler have the same interest--to know when they see a binding or a reference or an assignment whether the variable involved is private or public. When you make the default be 'public', the problem is that lots of things get made public that don't need to be, and this both makes it hard to optimize and makes it likely that errors will creep in due to unwanted assignments or even sometimes unwanted reads. > So take... > > (defvar x 1) > > (defun test() > (let ((x 10)) > (test2) > (message "test: %s" x))) > > (defun test2() > (setq x 20)) > > (test) > > x > > > Eval'ing (test) gives "test: 20", and x gives 1. > If you change the let to lexical-let you get > "test:10" and "20". This seems much more intuitive to me. Of course > its useful to be able to "subvert" the setq in test2 to not work on > the main defvar defined x, and I've used this occasionally. But in > general its likely to result in program errors, as the test function > needs to know that none of the functions it use a variable called x. > > Optimisation might be an issue as well of course, but processors are > fast these days! Its nice, but not essential. This sort of assumes a single-user machine. Server machines can be overloaded regardless of capacity. Efficiency determines the the size of the working set, the number of processes you can give the illusion of running at the same time when time-slicing, etc. Ultimately, when a server is overloaded, you have to buy a new machine. It's nice to stave this off by not being gratuitously inefficient. Further, even on a single-user machine, if you have other programs running in background (whether that means trying to get some editing done in Emacs during the half hour it takes Photoshop to start, or it means playing some compute-intensive video game on the same processor where you're editing), efficiency can still matter. You might assume emacs is not a server, but one of the good effects of merging CL and emacs might be that emacs could do more tasks that are often relegated to other programs and that those other programs could get some of the services emacs usually does. So the lines might get blurred.