In short, what's the difference?
(setq var1 `(,(get-internal-real-time)))
var1
-->(1358995178904535)
var1
-->(1358995178904535)
(setq var2 '(#.(get-internal-real-time)))
var2
-->(1358995195568422)
var2
-->(1358995195568422)
I thought that perhaps by "read-time eval" it meant that it would evaluate each time I read the variable, but I guess I was wrong, and quasiquote eval doesn't do that either.
An example where the difference matters:
* (defun foo () `(,(get-internal-real-time)))
FOO
* (defun bar () '(#.(get-internal-real-time)))
BAR
* (foo)
(44577)
* (foo)
(47651)
* (bar)
(41929)
* (bar)
(41929)
As you can see, when you're not using the value directly (as in the (setq var1 ...) case), the quasi-quote is expanded each time, returning different values. However, with the read-time eval, it's only called once, returning the same value again and again.
If you want to see read-time effects in isolation, using the REPL evaluating forms is not a good idea. REPL means READ EVAL PRINT LOOP. Every piece of code will be read, evaluated and print. Not just read.
Instead see this:
CL-USER > (read-from-string "`(,(get-internal-real-time))")
(LIST (GET-INTERNAL-REAL-TIME))
Above result depends a bit on the implementation, because the read version of a backquote list is not defined. But the effect is similar: the resulting form returned from the Lisp reader, is a call to LIST (or an equivalent) with the sub-form as an argument.
CL-USER > (read-from-string "'(#.(get-internal-real-time))")
(QUOTE (465370171))
Above executes the form at read-time and includes the value into the expression, which is the result of the read operation.
"read-time eval" means, that it would be evaluated each time the code itself is read. When you enter var2 in the REPL you don't read a variable, you access its value. So, in your case both forms produce the same result.
Related
I want to make a macro for binding variables to values given a var-list and a val-list.
This is my code for it -
(defmacro let-bind (vars vals &body body)
`(let ,(loop for x in vars
for y in vals
collect `(,x ,y))
,#body))
While it works correct if called like (let-bind (a b) (1 2) ...), it doesn't seem to work when called like
(defvar vars '(a b))
(defvar vals '(1 2))
(let-bind vars vals ..)
Then I saw some effects for other of my macros too. I am a learner and cannot find what is wrong.
Basic problem: a macro sees code, not values. A function sees values, not code.
CL-USER 2 > (defvar *vars* '(a b))
*VARS*
CL-USER 3 > (defvar *vals* '(1 2))
*VALS*
CL-USER 4 > (defmacro let-bind (vars vals &body body)
(format t "~%the value of vars is: ~a~%" vars)
`(let ,(loop for x in vars
for y in vals
collect `(,x ,y))
,#body))
LET-BIND
CL-USER 5 > (let-bind *vars* *vals* t)
the value of vars is: *VARS*
Error: *VARS* (of type SYMBOL) is not of type LIST.
1 (abort) Return to top loop level 0.
You can see that the value of vars is *vars*. This is a symbol. Because the macro variables are bound to code fragments - not their values.
Thus in your macro you try to iterate over the symbol *vars*. But *vars* is a symbol and not a list.
You can now try to evaluate the symbol *vars* at macro expansion time. But that won't work also in general, since at macro expansion time *vars* may not have a value.
Your macro expands into a let form, but let expects at compile time real variables. You can't compute the variables for let at a later point in time. This would work only in some interpreted code where macros would be expanded at runtime - over and over.
If you’ve read the other answers then you know that you can’t read a runtime value from a compiletime macro (or rather, you can’t know the value it will have at runtime at compiletime as you can’t see the future). So let’s ask a different question: how can you bind the variables in your list known at runtime.
In the case where your list isn’t really variable and you just want to give it a single name you could use macroexpand:
(defun symbol-list-of (x env)
(etypecase x
(list x)
(symbol (macroexpand x env))))
(defmacro let-bind (vars vals &body body &environment env)
(let* ((vars (symbol-list-of vars env))
(syms (loop for () in vars collect gensym)))
`(destructuring-bind ,syms ,vals
(let ,(loop for sym in syms for bar in vars collect (list var sym)) ,#body))))
This would somewhat do what you want. It will symbol-macroexpand the first argument and evaluate the second.
What if you want to evaluate the first argument? Well we could try generating something that uses eval. As eval will evaluate in the null lexical environment (ie can’t refer to any external local variables), we would need to have eval generate a function to bind variables and then call another function. That is a function like (lambda (f) (let (...) (funcall f)). You would evaluate the expression to get that function and then call it with a function which does he body (but was not made by eval and so captures the enclosing scope). Note that this would mean that you could only bind dynamic variables.
What if you want to bind lexical variables? Well there is no way to go from symbol to the memory location of a variable at runtime in Common Lisp. A debugger might know how to do this. There is no way to get a list of variables in scope in a macro, although the compiler knows this. So you can’t generate a function to set a lexically bound symbol. And it would be even harder to do if you wanted to shadow the binding although you could maybe do it with some symbol-macrolet trickery if you knew every variable in scope.
But maybe there is a better way to do this for special variables and it turns out there is. It’s an obscure special form called progv. It has the same signature that you want let-bind to have except it works. link.
In specified conditions I want to print name of fuction in this function. but I don't know how to get it.
In C++ I can use preprocessor macro __FUNCTION__. I something simmilar in AutoLISP?
This is definitely possible. Let's look at two situations:
1) You're writing the function.
This should be easy, just define a variable that has the same name as the function and you're good to go. (As discussed in the comments above.)
You could even use something more descriptive than the actual name of the function. (defun af () ...) could be called "Awesome Function" instead of "af".
I would also recommend using standard constant value formatting: Capital letters with underscores to separate words. (setq FUNCTION_NAME "AwesomeFunction"). (This is just like PI which is set for you and you shouldn't change it - it's a constant.)
2) You're calling a function that you might not know the name of until the code runs.
Some examples of this:
(apply someFunctionInThisVariable '(1 2 3))
(mapcar 'printTheNameOfAFunction '(+ setq 1+ foreach lambda))
(eval 'anotherFunctionInAVariable)
To print the name of a function stored in a variable - like this (setq function 'myFunction) - you need to use the (vl-princ-to-string) function.
(vl-princ-to-string function) ;; Returns "MYFUNCTION"
(strcase (vl-princ-to-string function) T) ;; Returns "myfunction"
(princ
(strcase
(vl-princ-to-string function)
T
)
) ;; Command line reads: myfunction
The (vl-princ-to-string) function can be used on any type that can be printed and will always return a string. It's great if you don't know whether you have a number or a word, etc.
Hope that helps!
P.S. I first used this technique when I was writing a testing function. Send it a function and an expected value and it would test to see if it worked as expected - including printing the function's name out as part of a string. Very useful if you have the time to setup the tests.
I want to define a list of accumulators with Emacs Lisp and write the following code, but I got a error saying that initV is a void variable. It seems initV is not evaluated in the function define-accum. Where is I make a mistake? (I just want to know why although I know there is other ways to reach my target.)
(defun define-accum (name initV)
(defalias name (lambda (v) (+ v initV))))
(setq accums '((myadd1 . 1)
(myadd2 . 2)))
(dolist (a accums)
(define-accum (car a) (cdr a)))
(message "result = %d" (+ (myadd1 1) (myadd2 1)))
You need to use backquotes properly. This would work for you, for instance:
(defun define-accum (name initV)
(defalias name `(lambda (v) (+ v ,initV))))
See here for an explanation
Apart from using backquotes, you can activate lexical binding (if you're using Emacs 24 or newer). For example, if I put your code in a .el file and put this on the first line:
;; -*- lexical-binding: t -*-
then I get the output:
result = 5
This works because the lambda function in define-accum will reference the initV in the environment where it's being defined (thus picking the variable in the argument list), and create a closure over this variable. With dynamic binding (the default), the function would look for initV in the environment where it's being called.
To add a little to what others have said -
If the variable (initV) is never actually used as a variable, so that in fact its value at the time the accumulator is defined is all that is needed, then there is no need for the lexical closure that encapsulates that variable and its value. In that case, the approach described by #juanleon is sufficient: it uses only the value at definition time - the variable does not exist when the function is invoked (as you discovered).
On the other hand, the lexical-closure approach lets the function be byte-compiled. In the backquote approach, the function is simply represented at runtime by a list that represents a lambda form. If the lambda form represents costly code then it can make sense to use the lexical-closure approach, even though (in this case) the variable is not really needed (as a variable).
But you can always explicitly byte-compile the function (e.g. ##NAME## in your define-accum. That will take care of the inefficiency mentioned in #2, above.
If in the REPL I do this:
(dolist (x (1 2 3))
(print x))
then I get an error since in (1 2 3) the digit 1 is not a symbol or a lambda expr.
If I do:
(dolist (x (list 1 2 3))
(print x))
then it works ok.
My question is why the following works:
REPL> (defmacro test (lst)
(dolist (x lst)
(print x)))
=> TEST
REPL> (test (1 2 3))
1
2
3
=>NIL
Why does dolist accept (1 2 3) when it is inside the macro definition but not when directly in the repl?
The assumption:
"Since TEST is a macro ,it does not evaluate its arguments, so (1 2 3) is passed as is to the dolist macro. So dolist must complain like it does when it is passed (1 2 3) in the REPL"
is obviously wrong. But where?
UPDATE: Although the answers help clarify some misunderstandings with macros, my question still stands and i will try to explain why:
We have established that dolist evaluates its list argument(code blocks 1, 2). Well, it doesnt seem to be the case when it is called inside a macro definition and the list argument that is passed to it is one of the defined macro arguments(code block 3). More details:
A macro, when called, does not evaluate its arguments. So my test macro, when it is called, will preserve the list argument and will pass it as it is to the dolist at expansion time. Then at expansion time the dolist will be executed (no backquotes in my test macro def). And it will be executed with (1 2 3) as argument since this is what the test macro call passed to it. So why doesnt it throw an error since dolist tries to evaluate its list argument, and in this case its list argument (1 2 3) is not evaluatable. I hope this clears my confusion a bit.
This form:
(defmacro test (lst)
(dolist (x lst)
(print x)))
defines a macro, which is a "code transformation function" which
gets applied to a form using this macro at macro expansion time. So,
after you have defined this macro, when you evaluate this expression:
(test (1 2 3))
it first gets read to this list:
(test (1 2 3))
Then, since Lisp reads test at the operator position, it gets
macro-expanded by passing the argument, which is the literal list (1
2 3), to the macro expansion function defined above. This means that
the following gets evaluated at macro-expansion time:
(dolist (x '(1 2 3))
(print x))
So, at macro-expansion time, the three values get printed. Finally,
the return value of that form is returned as the code to be compiled
and executed. Dolist returns nil here, so this is the code returned:
nil
Nil evaluates to nil, which is returned.
Generally, such a macro is not very useful. See "Practical Common
Lisp" by Peter Seibel or "On Lisp" by Paul Graham for an introduction
to useful macros.
Update: Perhaps it is useful to recapitulate the order of
reading, expanding, and evaluating Lisp code.
First, the REPL takes in a stream of characters: ( t e s t
( 1 2 3 ) ), which it assembles into
tokens: ( test ( 1 2 3 ) ).
Then, this is translated into a tree of symbols: (test (1 2
3)). There may be so-called reader macros involved in this step.
For example, 'x is translated to (quote x).
Then, from the outside in, each symbol in operator position (i.e., the
first position in a form) is examined. If it names a macro, then the
corresponding macro function is invoked with the code (i.e., the
subtrees of symbols) that is the rest of the form as arguments. The
macro function is supposed to return a new form, i.e. code, which
replaces the macro form. In your case, the macro test gets the code
(1 2 3) as argument, prints each of the symbols contained within
(note that this is even before compile time), and returns nil,
throwing its arguments away (the compiler never even sees your little
list). The returned code is then examined again for possible
macroexpansions.
Finally, the expanded code that does not contain any macro invocations
anymore is evaluated, i.e. compiled and executed. Nil happens to
be a self-evaluating symbol; it evaluates to nil.
This is just a rough sketch, but I hope that it clears some things up.
Your macro test does not return any code. And yes, macro arguments are not evaluated. If you want to see the same error, you have to define your macro as:
(defmacro test (lst)
`(dolist (x ,lst)
(print x)))
Generally when you have questions about macro expansions, referring to MACROEXPAND-1 is a great first step.
* (macroexpand-1 '(test (1 2 3)))
1
2
3
NIL
T
IE, what is happening is that the actual expansion is that sequence of prints.
Nil is what is returned by DOLIST, and is the expanded code.
Macros get their arguments passed unevaluated. They may choose to evaluate them. dolist does that for its list argument. It works with an unquoted list passed in for lst in your macro test:
(defmacro test (lst)
(dolist (x lst)
(print x)))
That's because at macro-expansion time the dolist sees lst as its argument. So when it evaluates it, it gets the list (1 2 3).
lst is a variable, when expand macro test, it also mean eval dolist structure. the first step is to eval the form lst, will get the lisp object (1 2 3).
like follow example:
(defmacro test (a)
(+ a 2))
(test 2) --> 4 ; mean invoke add function, and the first variable a binding a value 2.
I wrote this piece of code in common lisp (ignore the ... as it is pointless to paste that part here).
(case turn
(*red-player* ...)
(*black-player* ...)
(otherwise ...))
red-player and black-player are variables that were defined using defvar statement, in order to "simulate" a #define statement in C.
(defvar *red-player* 'r)
(defvar *black-player* 'b)
As you can imagine, when the variable turn receives either *red-player*'s value ('r) or *black-player*'s value ('b), the case statement doesn't work properly, as it expects that turn contains *red-player* as a literal, not the content of the variable *red-player*.
I know that I can easily fix that using a cond or if + equal statements, as the content of the variable is evaluated there, but I am curious. Maybe there is a way to create something like C's macros in Lisp, or there is some kind of special case statement that allows the use of variables instead of literals only.
Thank you in advance!
You can enter the value of expressions into your forms with read-time evaluation
CL-USER 18 > (defvar *foo* 'a)
*FOO*
CL-USER 19 > (defvar *bar* 'b)
*BAR*
CL-USER 20 > '(case some-var (#.*foo* 1) (#.*bar* 2))
(CASE SOME-VAR (A 1) (B 2))
Note that read-time evaluation is not necessarily the best idea for improving code maintenance and security.
Note also that the idea that there is a variable with a descriptive name for some internal value like is not necessary in Lisp:
dashedline = 4
drawLine(4,4,100,100,dashedline)
would be in Lisp
(draw-line 4 4 100 100 :dashed-line)
In Lisp one can pass descriptively named symbols. The sort of API that uses integer values or similar is only need in APIs to external software typically written in C.
The short answer is "yes, you can do it, sort of".
And the seeds of the longer answer involve the use of defmacro to create your own version of case, say mycase, that will return a regular case form. The macro you define would evaluate the head of each list in the case body.
You would call:
(mycase turn
(*red* ...)
(*black* ...)
(otherwise ...))
which would return
(case turn
((r) ...)
((b) ...)
(otherwise ...))
to the evaluator. The returned case form would then be evaluated in the way you want.
You'd then be free to continue programming in your c-esque fashion to the dismay of lispers everywhere! Win-win?
You can abuse Lisp in any way you like. It is flexible like that, unlike C.
It doesn't always like the uses you put it to. Why push Lisp around?
Try this approach:
(defvar *turn* nil)
(cond
((eq *turn* 'red)
...
(setq *turn* 'black)))
((eq *turn* 'black)
...
(setq *turn* 'red)))
(t
.......))