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.
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
...))
Adding (setq foo 1) to the code without defining the variable foo using defvar will result in the following warning generated by Emacs byte-compiler:
assignment to free variable `foo'
What are the dangers associated with assigning to such free variable without prior definition?
Emacs Lisp uses Dynamic Binding by default, so when you write
(defun my-fun-1 (...)
...
(setq foo 1)
...)
and get your warning, the code is equivalent to having (defvar foo) before the defun.
This means that the my-fun-1 above shares the value of foo with
(defun maybe-start-ww3 ()
(when (= 1 foo)
(launch-missiles)))
this is not always bad; much ELisp legacy code uses such globals to pass state. However, this is a very bad style, if you use the same variable name (e.g., date) for these purposes in two unrelated places, the consequences could be unpredictable.
In short, if you use the free variable in a single place, there is no reason not to bind it.
If you use it to pass state, you should defvar it and use a long name which is not likely to be used by someone else - and you should refactor your code to avoid that.
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>
I am new to macros. I am trying to write a macro to generate some functions:
(defmacro test (name)
`(defun ,(intern (concat "fun-" (symbol-name name))) ()
...))
I want to pass a symbol to this macro like (test 'stuff), but emacs gives me this error:
Debugger entered--Lisp error: (wrong-type-argument symbolp (quote stuff))
Is that telling me (quote staff) is not the right argument to symbol-name ? How can I fix this ?
This all seems OK. The only thing is that you should call your macro with an unquoted symbol, like this:
(test stuff)
The reason for this is that, as noted in the Emacs Lisp Manual :
Macros [...] operate on the unevaluated expressions for the arguments, not on the argument values as functions do.
When you pass symbols to functions, you are used to quote them to prevent them being considered as a variable name and evaluated to the associated value. However, macro arguments are not evaluated during the macro expansion, but afterwards, when the expansion itself gets evaluated.
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)