Why not quoting lambda? - emacs

I was told that I shouldn't quote lambda in, say,
(global-set-key (quote [f3]) '(lambda () (interactive) (other-window -1) ))
I tried that indeed if I don't quote lambda, it works equally well
(global-set-key (quote [f3]) (lambda () (interactive) (other-window -1) ))
However, I don't understand why the latter works (and is also being preferred, and now that the latter works, why the former also works).
If the lambda expression is defined as an other function, we would have called
(global-set-key (quote [f3]) 'my-function)
to prevent my-function to be evaluated immediately. I understand the lambda expression as an anonymous version of my-function. So why shouldn't lambda be quoted?
Thanks!

Using C-h f lambda <RET>:
A call of the form (lambda ARGS DOCSTRING INTERACTIVE BODY)
is self-quoting; the result of evaluating the lambda expression
is the expression itself.
So, this answers the question, why you don't need to quote the lambda expression. As to why you shouldn't do it... I think, this has to do with byte compilation. A quoted lambda expression is simply plain data. The byte code compiler has no choice but to include the expression as a constant list literal into its output. An unquoted lambda expression, on the other hand, can be compiled to byte code, resulting in faster execution.
List literals of the form (lambda (...) ...) are special-cased in emacs lisp evaluator and can be used as functions. That's why it works, regardless of whether you quote the lambda expression or not.

Related

Backquote expansion in Lisp

I'm a Lisp beginner and I'm struggling to understand why the following code gives me an error.
(dolist (elem '(mapcar
mapcon))
(when (fboundp `',elem) (print "hello")))
Thanks.
Edit:
A bit more context. I wrote the following in Elisp and I don't know how to fix it.
(dolist (ui-elem '(menu-bar-mode
tool-bar-mode
tooltip-mode
scroll-bar-mode
horizontal-scroll-bar-mode))
(when (fboundp `',ui-elem) (ui-elem -1)))
Note
In your question you mix common-lisp and elisp, but they are two different languages. The question however touches on concepts that are identical in both languages.
The need to quote symbols
The code you want to write checks if a symbol is bound to a function.
What you already know probably is that you can call fboundp on a symbol to determines this:
(fboundp 'menu-bar-mode)
=> t
When you evalute the above form, 'menu-bar-mode is the same as (quote menu-bar-mode), and is evaluated as the symbol object menu-bar-mode. This is the value that is given as an argument to fboundp.
In you example you want to iterate over a list of symbols, call fboundp on it and call the function if the symbol denotes a function. You can do this as follows:
(dolist (s '(menu-bar-mode and other symbols))
(when (fboundp s)
(funcall s -1)))
The list of symbols '(menu-bar-mode and other symbols) is quoted, which means that when dolist evaluates it, it sees a list of symbols. The value to which s is bound at each iteration of the loop is a symbol object, there is no need to quote them.
Quoting a symbol is something you have to do when writing them in your code so that they are not interpreted as variables. When you iterate over a list of symbols, you already manipulate symbols.
Note also that both Common Lisp and Emacs Lisp are "Lisp-2", meanings that you have to use (funcall ui-elem -1) instead of writing (ui-elem -1). When you write the latter form, that means calling the function literally named ui-elem because for function application, the first symbol in the list is not evaluated, it is taken literally.
Too many levels of quoting
The actual error I have when I execute your code is:
(wrong-type-argument symbolp 'mapcar)
It may look like 'mapcar denotes a symbol, because when you want the interpreter to evaluate some code as a symbol, you need to quote it. However, Lisp printers write objects in a way that they can be read back to "similar" objects. The error message that is printed if I expect a symbol to be a number is the following, where symbol foo is printed unquoted:
(+ 'foo 3)
;; error: (wrong-type-argument number-or-marker-p foo)
In your error message, the form that you are trying to use as a symbol is (quote mapcar). Recall that when you directly call fboundp:
(fboundp 'mapcar)
It is the same as-if you wrote:
(fboundp (quote mapcar))
First, (quote mapcar) is evaluated, as the symbol mapcar. Then, fboundp is applied to that value.
But when you write the following, while ui-elem is bound to symbol mapcar:
(fboundp `',ui-elem)
This is equivalent to:
(fboundp `(quote ,ui-elem))
The argument to fboundp is evaluated as (quote mapcar). You have one extra level of quoting. You could write instead:
(fboundp `,ui-elem)
But then, you don't need to use backquote/comma, you can directly write:
(fboundp ui-elem)

lambda macro in elisp

Here is the short lambda macro definition taken from subr.el.
(defmacro lambda (&rest cdr)
(list 'function (cons 'lambda cdr)))
The fact, this is a recursive macro puts me in a fix. can someone explain, how this works & what it returns:
(list 'function (cons 'lambda cdr))
The reason this is not a recursive macro is that function acts like quote in that it prevents evaluation of its argument. Therefore, a recursive call to the lambda macro will not be made.
The difference between function and quote is that function permits byte compilation of its argument, while quote always preserves it verbatim. Thus, if you write (lambda () 1), it will be expanded to (function (lambda () 1)), and then replaced with byte code by the compiler.
It is not a recursive macro. Emacs Lisp macros have the form (SYMBOL...). It is only such a form that gets defined as a macro, and which is expanded. The occurrence of the symbol lambda in the macro definition body is not expanded. It is a ( followed by the symbol lambda and a possibly empty list of sexps, and then a ) that is matched and expanded.
The macro expansion returns the list (function (lambda CDR)), where CDR is the (unevaluated) list of sexps passed as args to the macro. When that list is evaluated it returns the list (lambda CDR), with the same (unevaluated) CDR.

Passing a symbol to a macro in emacs

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.

Why is (commandp '(customize-option 'foo)) nil?

I want to bind customize-option for a certain variable to a key, since I need to change it rather often. I have two options:
(global-set-key (kbd "<f12>") '(lambda() (interactive) (customize-option 'my-variable) ) )
(global-set-key (kbd "<f12>") '(customize-option 'my-variable )
The first one works, the second does not, because commandp complains that customize-option is not a command. Why? As far as I know, customize-option is an interactive function, so commandp should be t:
customize-option is an interactive compiled Lisp function.
It is bound to .
(customize-option SYMBOL)
Customize SYMBOL, which must be a user option variable.
It is the form (customize-option 'my-variable) which is not a command. You cannot bind to an arbitrary quoted form, any more than you can bind to a literal string or an unbound symbol. Some of those would be useful to bind to, but it's not hard to work around the limitations. Write a macro if you find it hard to live with. (As the saying goes, now you have two problems.)
The second argument to global-set-key must be a command definition, typically a symbol naming an interactive function. An interactive function is a function that begins with the (interactive) form. For example:
(defun delete-to-end ()
"Delete text from point to the end of buffer."
(interactive)
(delete-region (point) (point-max)))
This defines an interactive function and assigns it to the symbol delete-to-end. After that, delete-to-end is a valid command that you can pass to global-set-key:
(global-set-key [f12] 'delete-to-end)
Without the (interactive) line, delete-to-end would still name a function callable from Lisp programs, but it would not be a "command". Since it is marked interactive, (commandp 'delete-to-end) returns true, and M-x delete-to-end works.
Interactive functions don't need to be bound to a symbol, they can be anonymous. Like any other anonymous functions, they are created using a lambda form, except that for commands it must also include (interactive). Anonymous commands can be passed as the second argument to global-set-key without assigning them to a symbol, so the following definition is equivalent to the one above:
(global-set-key [f12]
(lambda ()
"Delete text from point to the end of buffer."
(interactive)
(delete-region (point) (point-max))))
...except it's somewhat less readable, and looks uglier when inspected with C-h c
or C-h k.
In your case, the first call to global-set-key is given a valid command (a quoted lambda form is itself a valid function), but the second one isn't, it is given a two-element list that can neither be called nor satisfies the requirement of being marked "interactive".

lisp macro expand with partial eval

I have following code which confuse me now, I hope some can tell me the difference and how to fix this.
(defmacro tm(a)
`(concat ,(symbol-name a)))
(defun tf(a)
(list (quote concat) (symbol-name a)))
I just think they should be the same effect, but actually they seem not.
I try to following call:
CL-USER> (tf 'foo)
(CONCAT "FOO")
CL-USER> (tm 'foo)
value 'FOO is not of the expected type SYMBOL.
[Condition of type TYPE-ERROR]
So, what's the problem?
What i want is:
(tm 'foo) ==> (CONCAT "FOO")
The first problem is that 'foo is expanded by the reader to (quote foo), which is not a symbol, but a list. The macro tries to expand (tm (quote foo)). The list (quote foo) is passed as the parameter a to the macro expansion function, which tries to get its symbol-name. A list is not a valid argument for symbol-name. Therefore, your macro expansion fails.
The second problem is that while (tm foo) (note: no quote) does expand to (concat "FOO"), this form will then be executed by the REPL, so that this is also not the same as your tf function. This is not surprising, of course, because macros do different things than functions.
First, note that
`(concat ,(symbol-name a))
and
(list (quote concat) (symbol-name a))
do the exact same thing. They are equivalent pieces of code (backquote syntax isn't restricted to macro bodies!): Both construct a list whose first element is the symbol CONCAT and whose second element is the symbol name of whatever the variable A refers to.
Clearly, this only makes sense if A refers to a symbol, which, as Svante has pointed out, isn't the case in the macro call example.
You could, of course, extract the symbol from the list (QUOTE FOO), but that prevents you from calling the macro like this:
(let ((x 'foo))
(tm x))
which raises the question of why you would event want to force the user of the macro to explicitly quote the symbol where it needs to be a literal constant anyway.
Second, the way macros work is this: They take pieces of code (such as (QUOTE FOO)) as arguments and produce a new piece of code that, upon macroexpansion, (more or less) replaces the macro call in the source code. It is often useful to reuse macro arguments within the generated code by putting them where they are going to be evaluated later, such as in
(defmacro tm2 (a)
`(print (symbol-name ,a)))
Think about what this piece of code does and whether or not my let example above works now. That should get you on the right track.
Finally, a piece of advice: Avoid macros when a function will do. It will make life much easier for both the implementer and the user.