I was experimenting with interplay between Emacs lexical scoping (new feature of Emacs 24) and add-to-list and found the interplay confusing and I don't know how to make sense of it. Here is a minimal example, except I use set instead of add-to-list. (set is similar to add-to-list in that it usually takes a quoted variable name)
(eval
'(progn
(setq a "global")
(let ((a "apple"))
(defun my-print-a ()
(print a)
(set 'a "by set")
(print a))
(setq a "mature apple"))
(let ((a "banana"))
(my-print-a))
(print a))
t) ;; t for lexical scoping
Above code prints "mature apple", "mature apple", "by set" in order. The first print result, "mature apple", is as expected for lexical scoping (with support for lexical closures), nothing surprising to see here. But the results of the second and the third print are surprising to me. It's as if (set 'a "by set") is only recognizing and affecting the global binding of the name a.
Is this an intended behavior? Or is this a bug? If intended, how does one make sense of this behavior?
Am I right in assuming that it's always the global binding that set affects as long as lexical scoping is on?
With (eval '(progn ...) nil), things work as expected of dynamic scoping and the behavior of (set 'a ...) is the same as that of (setq a ...) in that case. Only when one uses lexical scoping and a quoted variable together, this gotcha shows up.
Update:
it seems to be an intended behavior according to the manual. On Void Variables, manual says
Under lexical binding rules, the value cell only holds the variable's global value, i.e. the value outside of any lexical binding construct. When a variable is lexically bound, the local value is determined by the lexical environment; the variable may have a local value if its symbol's value cell is unassigned.
and on Lexical Binding
functions like symbol-value, boundp, and set only retrieve or modify a variable's dynamic binding (i.e. the contents of its symbol's value cell).
symbol-value, boundp, set are functions usually called with quoted variable names ((symbol-value 'var) (boundp 'var) (set 'var 123)). These functions only get or set a symbol's value cell, and under lexical binding rules, the value cell only holds the global value. So under lexical binding, use of quoted variables only get or set global values (unless the variable is a special variable). Although it still seems odd in that the result is neither lexical (apple) nor dynamic (banana).
The code is not written in the way that Emacs expects a lexical-scoping-enabled program to be written.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Definitions.html
defvar and defconst are special forms that define a symbol as a global variable—a variable that can be accessed at any point in a Lisp program.
(...)
In principle, you can assign a variable value to any symbol with setq, whether not it has first been defined as a variable. However, you ought to write a variable definition for each global variable that you want to use; otherwise, your Lisp program may not act correctly if it is evaluated with lexical scoping enabled.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical-Binding.html
Note that functions like symbol-value, boundp, and set only retrieve or modify a variable's dynamic binding (i.e. the contents of its symbol's value cell). Also, the code in the body of a defun or defmacro cannot refer to surrounding lexical variables.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Setting-Variables.html
Special Form: setq [symbol form]...
This special form is the most common method of changing a variable's value. (...) The current binding of the symbol is changed.
(...)
Function: set symbol value
This function puts value in the value cell of symbol.
(...)
When dynamic variable binding is in effect (the default), set has the same effect as setq, apart from the fact that set evaluates its symbol argument whereas setq does not. But when a variable is lexically bound, set affects its dynamic value, whereas setq affects its current (lexical) value.
If we add defvar that defines a as a global variable, we can see that all the references to a in the my-print-a function turn out to be dynamically bound as the manual explains:
(eval
'(progn
(defvar a nil)
(setq a "global")
(let ((a "apple"))
(defun my-print-a ()
(print a) ; "banana"
(set 'a "by set")
(print a)) ; "by set"
(setq a "mature apple"))
(let ((a "banana"))
(my-print-a))
(print a)) ; "global"
t)
Related
I just met an unusual situation in my common lisp code when I wanna test locally and declare:
(defvar test-out 2) ;; make a dynamic variable
;; function below just simply re-write from locally doc
(defun test (out)
(declare (special out))
(let ((out 1))
(print out) ;; => 1
(print (locally (declare (special out)) out)))) ;; => 2
;; when argument has same name as outside dynamic variable
(defun test1 (test-out)
(declare (special test-out))
(let ((test-out 1))
(print test-out) ;; => 1
(print (locally (declare (special test-out)) test-out)))) ;; => also 1
I know the right name of dynamic variable should be *test-out*, but I thought it just for programmer to tell dynamic variable conveniently.
I am a bit confuse about test1 function, it looks like locally declare do not point test-out to dynamic variable outside.
Can anyone explain to me test1 function's behavior? Thanks
Update:
I give a new dynamic variable (defvar test-out-1 3), and call it like (test1 test-out-1), still get print out result 1 and 1.
I change test1's argument name from test-out to test-out1, recompile test1, and problem disappears, print out results are 1 and 2 when I call (test1 test-out).
I change (defvar test-out 2) to (defvar test-out-1 2) (change dynamic variable name). Then recompile whole file (no dynamic variable called test-out this time, and test1 argument's name is test-out), problem disappears.
After 3, I call (defvar test-out 2), and (test1 test-out). This time, it prints out right answers: 1 and 2.
After 4, I recompile test1 again, then run (test1 test-out), it prints out 1 and 1 again, problem appears again.
If I guess right, when test1 compiling, for some reason, its arguments' name connect to dynamic variable test-out. That's why I receiving wrong result when I even call with different value, however, problem is solved by itself when I recompile test1 with different argument name or clean dynamic variable test-out before recompile test.
If so, I still do not understand why compile function will effect by dynamic variable in the environment.
DEFVAR declares a variable to be special - that means they will use dynamic bindings when bound and access to such a variable will look for dynamic bindings. Globally and on all binding levels. For now and in the future.
From then on, ALL uses and bindings of that variable in new code will be declared special automatically. Even local LET bindings. On all levels. There is no way to declare it unspecial. Thus a local special declaration in your test1 function now is not needed, it already is declared special. Every use or binding of it, even without explicit declaration is now using dynamic binding.
That's also the reason why any DEFVAR or DEFPARAMETER variable should be written as *variablename*, to prevent accidentally declaring all variables with the same name to be special.
Avoid:
(defvar x 10) ; here X is explicitly declared special
(defun foo (x) ; here X is implicitly declared special
(let ((x ...)) ; here X is implicitly declared special
...))
Do:
(defvar *x* 10) ; here *X* is declared special
(defun foo (x) ; here X is lexical
(let ((x ...)) ; here X is lexical
...))
In another question regarding local variable definitions in Elisp, both respondents advise that let is appropriate and emphasize that it will not define the variable to be local to the function. The variable is local only to the let statement.
What is the distinction between local to let and local to the function? Is there another construct which would define the variable for the scope of the function?
The function using a let statement looks this:
(defun test-search (string)
"Searches for STRING in document.
Displays message 'Found!' or 'Not found...'. Places point after word
when found; fixed otherwise."
(interactive "sEnter search word: ")
(let ((found (save-excursion
(beginning-of-buffer)
(search-forward string nil t nil))))
(if found
(progn
(goto-char found)
(message "Found!"))
(message "Not found..."))))
Since the let makes up the whole body of your function in your example, your "variables local to let" are indistinguishable from "variables local to the function".
For that reason, no there is no separate construct to introduce variables local to a function. let is that construct, which can be used for variables valid over the whole function, or for variables valid over a small subset, depending on where you place the let.
What is the distinction between local to let and local to the function?
The question is slightly open to interpretation, but here I am interpreting "local to the function" as meaning that code which is not part of the function cannot see the variable, and by default in Emacs that is not the case for a let binding (or indeed for variable bindings in general).
To understand in detail you need to understand the difference between dynamic binding and lexical binding (and there are good explanations of this elsewhere, so you can follow this up yourself). To briefly demonstrate the difference, however, consider the following functions:
(defun func1 ()
(let ((foo 42))
(func2)))
(defun func2 ()
(bound-and-true-p foo))
The result of func1 is the result of func2, which in turn depends on whether a variable foo is visible to the latter function.
Under the default dynamic binding, calling func1 will return 42, because the scope of the binding of foo is the duration of the let, which incorporates the call to func2.
Under lexical binding, calling func1 will return nil, because foo (which has not otherwise been declared dynamic) has a binding which is local to func1 and therefore func2 cannot see it).
I'm actually being slightly misleading when talking about "local to the function" with respect to the above example, as the scope of the foo binding is strictly the scope of the let form rather than the scope of the function. The behaviour is not restricted to only let bindings though, so we could also use the following example, comparing the result of (func3 42) under dynamic and lexical binding:
(defun func3 (foo)
(func4))
(defun func4 ()
(bound-and-true-p foo))
Shown in following IELM session, defining a variable using defvar without initial value does not define the symbol for the variable.
Then why use defvar without initial value? Is it just for documentation and/or compiler help?
ELISP> foo
*** Eval error *** Symbol's value as variable is void: foo
ELISP> (boundp 'foo)
nil
ELISP> (defvar foo)
foo
ELISP> (boundp 'foo)
nil
ELISP> (defvar foo t)
foo
ELISP> (boundp 'foo)
t
ELISP>
This syntax is used to tell the byte compiler that a variable exists, when it does not otherwise know that to be true, thus avoiding compilation warnings.
This is described in the manual at C-hig (elisp) Compiler Errors :
• You can tell the compiler that a function is defined using
‘declare-function’. *Note Declaring Functions::.
• Likewise, you can tell the compiler that a variable is defined
using ‘defvar’ with no initial value. (Note that this marks the
variable as special.) *Note Defining Variables::.
It also tells Emacs that the variable uses dynamic binding (i.e. is "special", as mentioned in the quote). In Emacs Lisp this is the default, of course; but in libraries for which lexical binding has been enabled, even if you have no particular need to give the variable an initial value, it is necessary to do this if the variable is to be bound dynamically.
The defvar docstring also indicates this latter point: C-hf defvar :
The `defvar' form also declares the variable as "special",
so that it is always dynamically bound even if `lexical-binding' is t.
I'm programming on Ubuntu using GCL. From the documentation on Common Lisp from various sources, I understand that let creates local variables, and setq sets the values of existing variables. In cases below, I need to create two variables and sum their values.
Using setq
(defun add_using_setq ()
(setq a 3) ; a never existed before , but still I'm able to assign value, what is its scope?
(setq b 4) ; b never existed before, but still I'm able to assign value, what is its scope?
(+ a b))
Using let
(defun add_using_let ( )
(let ((x 3) (y 4)) ; creating variables x and y
(+ x y)))
In both the cases I seem to achieve the same result; what is the difference between using setq and let here? Why can't I use setq (since it is syntactically easy) in all the places where I need to use let?
setq assigns a value to a variable, whereas let introduces new variables/bindings. E.g., look what happens in
(let ((x 3))
(print x) ; a
(let ((x 89))
(print x) ; b
(setq x 73)
(print x)) ; c
(print x)) ; d
3 ; a
89 ; b
73 ; c
3 ; d
The outer let creates a local variable x, and the inner let creates another local variable shadowing the inner one. Notice that using let to shadow the variable doesn't affect the shadowed variable's value; the x in line d is the x introduced by the outer let, and its value hasn't changed. setq only affects the variable that it is called with. This example shows setq used with local variables, but it can also be with special variables (meaning, dynamically scoped, and usually defined with defparameter or defvar:
CL-USER> (defparameter *foo* 34)
*FOO*
CL-USER> (setq *foo* 93)
93
CL-USER> *foo*
93
Note that setq doesn't (portably) create variables, whereas let, defvar, defparameter, &c. do. The behavior of setq when called with an argument that isn't a variable (yet) isn't defined, and it's up to an implementation to decide what to do. For instance, SBCL complains loudly:
CL-USER> (setq new-x 89)
; in: SETQ NEW-X
; (SETQ NEW-X 89)
;
; caught WARNING:
; undefined variable: NEW-X
;
; compilation unit finished
; Undefined variable:
; NEW-X
; caught 1 WARNING condition
89
Of course, the best ways to get a better understanding of these concepts are to read and write more Lisp code (which comes with time) and to read the entries in the HyperSpec and follow the cross references, especially the glossary entries. E.g., the short descriptions from the HyperSpec for setq and let include:
SETQ
Assigns values to variables.
LET
let and let* create new variable bindings and execute a series
of forms that use these bindings.
You may want to read more about variables and bindings. let and let* also have some special behavior with dynamic variables and special declarations (but you probably won't need to know about that for a while), and in certain cases (that you probably won't need to know about for a while) when a variable isn't actually a variable, setq is actually equivalent to setf. The HyperSpec has more details.
There are some not-quite duplicate questions on Stack Overflow that may, nonetheless, help in understanding the use of the various variable definition and assignment operators available in Common Lisp:
setq and defvar in lisp
What's difference between defvar, defparameter, setf and setq
Assigning variables with setf, defvar, let and scope
In Lisp, how do I fix "Warning: Assumed Special?" (re: using setq on undefined variables)
Difference between let* and set? in Common Lisp
Let should almost always be the way you bind variables inside of a function definition -- except in the rare case where you want the value to be available to other functions in the same scope.
I like the description in the emacs lisp manual:
let is used to attach or bind a symbol to a value in such a way that the Lisp interpreter will not confuse the variable with a variable of the same name that is not part of the function.
To understand why the let special form is necessary, consider the situation in which you own a home that you generally refer to as ‘the house,’ as in the sentence, “The house needs painting.” If you are visiting a friend and your host refers to ‘the house,’ he is likely to be referring to his house, not yours, that is, to a different house.
If your friend is referring to his house and you think he is referring to your house, you may be in for some confusion. The same thing could happen in Lisp if a variable that is used inside of one function has the same name as a variable that is used inside of another function, and the two are not intended to refer to the same value. The let special form prevents this kind of confusion.
-- http://www.gnu.org/software/emacs/manual/html_node/eintr/let.html
(setq x y) assigns a new value y to the variable designated by the symbol x, optionally defining a new package-level variable 1. This means that after you called add_using_setq you will have two new package-level variables in the current package.
(add_using_setq)
(format t "~&~s, ~s" a b)
will print 3 4 - unlikely the desired outcome.
To contrast that, when you use let, you only assign new values to variables designated by symbols for the duration of the function, so this code will result in an error:
(add_using_let)
(format t "~&~s, ~s" a b)
Think about let as being equivalent to the following code:
(defun add-using-lambda ()
(funcall (lambda (a b) (+ a b)) 3 4))
As an aside, you really want to look into code written by other programmers to get an idea of how to name or format things. Beside being traditional it also has some typographic properties you don't really want to loose.
1 This behaviour is non-standard, but this is what happens in many popular implementations. Regardless of it being fairly predictable, it is considered a bad practice for other reasons, mostly all the same concerns that would discourage you from using global variables.
SETQ
you can get the value of the symbol out of the scope, as long as Lisp is still running. (it assign the value to the symbol)
LET
you can't get the value of the symbol defined with LET after Lisp has finished evaluating the form. (it bind the value to the symbol and create new binding to symbol)
consider example below:
;; with setq
CL-USER> (setq a 10)
CL-USER> a
10
;; with let
CL-USER> (let ((b 20))
(print b))
CL-USER> 20
CL-USER> b ; it will fail
; Evaluation aborted on #<UNBOUND-VARIABLE B {1003AC1563}>.
CL-USER>
numberp is a predicate in Lisp, and (numberp 1) returns T as expected. But if I only type numberp in the console, it prompts that the variable name is undefined.
What's the difference between these 2?
The question is slightly wrong already.
We are talking about different things in Common Lisp:
symbol : that's a data structure in Lisp. A symbol is a data object with a name, a value, a function, a package and possibly more.
In Common Lisp the symbol can have both a value and a function (or macro).
a variable is an identifier for a value in Lisp code
There are top-level variables defined by DEFVAR and DEFPARAMETER. There are also local variables defined by LAMBDA, DEFUN, LET, LET* and others.
(defun foo (i-am-a-variable) ...)
(defparameter *i-am-a-global-variable* ...)
a named function is an identifier for a function in Lisp code. Named functions are introduced on the top-level by DEFUN, DEFGENERIC and DEFMETHOD. There are also local named functions defined by FLET and LABELS.
Example:
(defun i-am-a-function (foo) ...)
(flet ((i-am-a-function (foo) ...)) ...)
To further complication function names and variable names are symbols in the source code.
Example:
(type-of (second '(defun foo () nil))) --> SYMBOL
Let's look at functions and variables:
(defun foo ()
(let ((some-name 100))
(flet ((some-name (bar) (+ bar 200)))
(+ some-name (some-name some-name)))))
Above code uses a variable and a function with the same symbol in the source code. Since functions and variables have their own namespace, there is no collision.
(+ some-name (some-name some-name))
Above then means we add the variable to the result of the function call on the variable.
This has the practical effect that you can do something like this:
(defun parent (person) ...)
(defun do-something (parent)
(parent parent))
You don't have to fear that your local variable names will shadow a global (or local) function. They simply are in different namespaces.
In Scheme there is only one namespace and we have to write
(define (foo lst) (list 'a lst 'n))
where in Common Lisp we can write:
(defun foo (list) (list 'a list 'n))
In Common Lisp there is no need to write lst instead of list - because there is no clash between the local variable list and the global function list.
Accessing the other namespace
To get a function object stored in a variable you can use FUNCTION.
(let ((my-function (function numberp)))
(funcall my-function 10))
(function foo) can be written shorter as #'foo.
FUNCALL calls a function object.
OTOH, if you want to store a function object from a variable in the function namespace, there is only one way:
(setf (symbol-function 'foo) my-function)
It is also necessary that the object is really a function and not something else (a number, a string, ...). Otherwise you'll see an error.
The side effect of this is that a Common Lisp never has to check if in (foo bar) the FOO is really a function. There is no possibility that it can be other than a function or undefined.
Functions and variables live in different namespaces in Common Lisp.
So when you use a name in a position where a function is expected (i.e. at the head of a list that is being evaluated), it looks for a function (or macro) with that name. If you use the same name at a position where a variable is expected, it looks for a variable with that name.
In your case there is a function named numberp, but not variable named numberp, so the second case causes an error.
One of the differences between Scheme (one Lisp dialect, so to speak) and Common Lisp is that in Scheme, there is one namespace for variables and functions, whereas in CL, there are two separate namespaces.
Thus, in Scheme, "define" sets this one-and-only name-to-value assoc, whereas in CL, there is "define" for the value and "defun" for the function association.
So, in CL you can:
(define foo ...something...)
(defun foo ...somethingElse...)
to confuse the reader.
In Scheme, there is only one:
(define foo something)
If this is good or bad has been an almost religious dispute in the past...