Re: Differences between Elisp and Lisp

[Kent M Pitman <pitman@world.std.com>]

Phillip Lord <p.lord@russet.org.uk> writes:

> >>>>> "Kent" == Kent M Pitman <pitman@world.std.com> writes:
> 
>   Kent> Thomas Link <samul@web.de> 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.