This question already has answers here:
Common lisp push from function
(4 answers)
Closed 1 year ago.
I want to write a function in Common Lisp, which destructively modifies its argument. In C or Rust I would use a pointer/reference to an object, which can be dereferenced inside the body of the function. In CL I write:
(defun foo (lst)
(setf lst NIL))
But after evaluating this form:
(let ((obj (list "a" "b")))
(foo obj)
obj) => ("a" "b")
one sees that the function foo has no effect. I can explain that by pass by value semantic, where we modify a local copy of the argument pushed onto the function stack.
If we define another function:
(defun bar (lst)
(setf (car lst) NIL))
and evaluate a similar form
(let ((obj (list "a" "b")))
(bar obj)
obj) => (NIL "b")
we will clearly see that the lst was modified as if we would use the pass by reference semantic. So, (setf lst NIL) did not worked but (setf (car lst) NIL) did. Could you please explain why?
Common Lisp passes arguments by value, but in most cases (other than primitive value types like fixnums or floats) the value is a reference. This is the same way that most managed languages work (e.g. Java, Python, JS).
In the LET-form, the value of the variable OBJ is a reference to a list, not the list itself. That reference is passed by value, so that inside the functions, the value of the parameter LST is another reference to the same list.
In FOO, the reference value is replaced with NIL, but the list that was previously referred to is not touched at all. In BAR, the list is retrieved from the heap and its CAR is replaced with NIL. Since OBJ holds a reference to the same list, the modification affects it as well.
For some operations the usual style is this:
(let ((obj (list "a" "b")))
(setf obj (nbar obj)) ; nbar is destructively modifying the list argument
(foo obj))
Above uses SETF to use the return value to change the binding of obj, since the function nbar itself can't do it.
Since NBAR has no access to the lexical variable obj and thus can't change it, one is supposed to return the object from NBAR and then one sets the variable to the result value - overwriting the previous binding.
Examples, where this rule is applicable: calls to sort, nreverse, ...
Related
This question already has an answer here:
Test if array is inside a list in lisp
(1 answer)
Closed 1 year ago.
Common Lisp.
I'm trying to determine if a string is present in a given list.
My goal is to have
(member searched-string my-list)
but I keep getting NIL.
Why does (member "foo" '("foo" "bar")) return NIL?
The default value for the :test keyword parameter is #'eql:
If neither a :test nor a :test-not argument is supplied, it is as if a :test argument of #'eql was supplied.
17.2.1 Rules about Test Functions - Satisfying a Two-Argument Test
Strings are not numbers nor characters, so two strings are eql only if they are eq (identical), but in your example you probably have two different strings allocated. You could have optimizations where string= strings are interned by the compiler, making them eq, but that would be an implementation detail.
Here below, the same foo string is used to build the list, and as an argument to member, and the call actually find the value:
(let ((foo "foo"))
(member foo (list foo "bar")))
=> ("foo" "bar")
But more generally, you want to pass a string comparison function, like string-equal (case-insensitive) or string= (exact case), or simply a general-purpose equality predicate; both examples below find the sarch string:
(member "foo" '("foo" "bar") :test #'equal)
(member "FOO" '("foo" "bar") :test #'equalp)
It's because (eql "foo" "foo") ; ==> nil. While not documented in the CLHS member uses #'eql as the standard test. To get it to use #'equal that also evaluates t for structures that display the same
(equal "foo" "foo") ; ==> t
(member "foo" '("foo" "bar") :test #'equal) ; ==> ("foo" "bar")
A string is stored as an vector of characters and thus unless it is the same object eq and eql will evaluate to nil while equal checks if all the characters in the strings are eql.
NB: (eql "foo" "foo") can also be t. Since it is literals and thus constant data the same code compiled will in some implementation only store "test" once so that they become pointer equal (eq).
I'm doing a tutorial on emacs lisp, and it's talking about the let function.
;; You can bind a value to a local variable with `let':
(let ((local-name "you"))
(switch-to-buffer-other-window "*test*")
(erase-buffer)
(hello local-name)
(other-window 1))
I don't understand the role of the double parentheses after let in the first line. What are they doing that a single set wouldn't do? Running that section without them, I get an error: Wrong type argument: listp, "you".
You can introduce multiple variables there. The outer parentheses delimit the list of bindings, the inner the individual binding form.
(let ((foo "one")
(bar "two"))
(frobnicate foo bar))
There are not "double parens".
Presumably, you are thinking of (let ((foo...)...)), and you mean the (( that come after let? If so, consider this:
(let (a b c) (setq a 42)...)
IOW, let declares local variables. It may also bind them. In the previous sexp, it declares a, b, and c, but it doesn't bind any of them, leaving it to the let body to give them values.
An example that declares two variables but binds only one of them (a):
(let ((a 42) b) ... (setq b ...) ...)
According to gnu.org, it looks like you can construct and initialize multiple variables with one let statement, so the double parenthesis is there to allow the separation between the variables.
If the varlist is composed of two-element lists, as is often the case, the template for the let expression looks like this:
(let ((variable value)
(variable value)
…)
body…)
The let special form takes a list of bindings: (let (<binding-form> ...) <body>).
The binding form is one of <symbol> (denoting a variable bound to the value nil) or a list (<symbol> <value>) (where value is computed when the let is entered).
The difference between let and let* is how the "value" bits are executed. For plain let, they're executed before any of the values are bound:
(let ((a 17)
(b 42))
(let ((a b) ; Inner LET
(b a))
(list a b)))
Whereas let* executes the binding forms one after another. Both have their places, but you can get by with only using let since (let* (<form1> <form2>...) is equivalent to (let (<form1>) (let (<form2>) ...))
In Common Lisp, the special operator quote makes whatever followed by un-evaluated, like
(quote a) -> a
(quote {}) -> {}
But why the form (quote ()) gives me nil? I'm using SBCL 1.2.6 and this is what I got in REPL:
CL-USER> (quote ())
NIL
More about this problem: This is some code from PCL Chapter 24
(defun as-keyword (sym)
(intern (string sym) :keyword))
(defun slot->defclass-slot (spec)
(let ((name (first spec)))
`(,name :initarg ,(as-keyword name) :accessor ,name)))
(defmacro define-binary-class (name slots)
`(defclass ,name ()
,(mapcar #'slot->defclass-slot slots)))
When the macro expand for the following code:
(define-binary-class id3-tag
((major-version)))
is
(DEFCLASS ID3-TAG NIL
((MAJOR-VERSION :INITARG :MAJOR-VERSION :ACCESSOR MAJOR-VERSION)))
which is NIL rather than () after the class name ID3-TAG.
nil and () are two ways to express the same concept (the empty list).
Traditionally, nil is used to emphasize the boolean value "false" rather than the empty list, and () is used the other way around.
The Common LISP HyperSpec says:
() ['nil], n. an alternative notation for writing the symbol nil, used
to emphasize the use of nil as an empty list.
Your observation is due to an object to having more than one representation. In Common Lisp the reader (that reads code and reads expressions) parses text to structure and data. When it's data the writer can print it out again but it won't know exactly how the data was represented when it was initially read in. The writer will print one object exactly one way, following defaults and settings, even though there are several representations for that object.
As you noticed nil, NIL, nIL, NiL, ... ,'nil, 'NIL, (), and '() are all read as the very same object. I'm not sure the standard dictates exactly how it's default representation out should be so I guess some implementations choose one of NIL, nil or maybe even ().
With cons the representation is dependent on the cdr being a cons/nil or not:
'(a . nil) ; ==> (a)
'(a . (b . c)) ; ==> (a b . c)
'(a . (b . nil)) ; ==> (a b)
With numbers the reader can get hints about which base you are using. If no base is used in the text it will use whatever *read-base* is:
(let ((*read-base* 2)) ; read numbers as boolean
(read-from-string "(10 #x10)")) ; ==> (2 16)
#x tells the reader to interpret the rest as a hexadecimal value. Now if your print-base would have been 4 the answer to the above would have been visualized as (2 100).
To sum it up.. A single value in Common Lisp may have several good representations and all of them would yield the very same value. How the value is printed will follow both implementation, settings and even arguments to the functions that produce them. Neither what it accepts as values in or the different ways it can visualize the value tells nothing about how the value actually gets stored internally.
I am not sure what is going on here, a macro example in the text.
Basically, not comfortable with how to use get-setf-method, a built-in macro (maybe function?).
To be specific, how about the case that some of the return values of get-setf-method are nil?
e.g.
(get-setf-method 'x)
NIL ;
NIL ;
(#:NEW-3069) ;
(SETQ X #:NEW-3069) ;
X
And why this example code set the fifth return value to the second return value first, for initialization?
Finally how it can handle the order of setting the variables in an expression, such as (aref ar (incf i)
(get-setf-method '(aref ar (incf i)))
(#:G3070 #:G3071) ;
(AR (INCF I)) ;
(#:G3072) ;
(SYSTEM::STORE #:G3070 #:G3071 #:G3072) ;
(AREF #:G3070 #:G3071)
Here is the definition of the macro :
(defmacro sortf (op &rest places)
(let* ((meths (mapcar #'(lambda (p)
(multiple-value-list
(get-setf-method p)))
places))
(temps (apply #'append (mapcar #'third meths))))
`(let* ,(mapcar #'list
(mapcan #'(lambda (m)
(append (first m)
(third m)))
meths)
(mapcan #'(lambda (m)
(append (second m)
(list (fifth m))))
meths))
,#(mapcon #'(lambda (rest)
(mapcar
#'(lambda (arg)
`(unless (,op ,(car rest) ,arg)
(rotatef ,(car rest) ,arg)))
(cdr rest)))
temps)
,#(mapcar #'fourth meths))))
That's actually some older code. get-setf-method was actually replaced by get-setf-expansion as described in Issue SETF-METHOD-VS-SETF-METHOD Writeup. So what you should be interested in these days is get-setf-expansion. The values that it returns are the pieces of code that you need to safely store a value in a location. This is very important because it's very easy to write modyfing macros incorrectly.
As to why some of the values can be nil, one of the examples in the documentation for get-setf-expansion actually shows how some of the values can be nil:
(get-setf-expansion 'x)
;=> NIL, NIL, (#:G0001), (SETQ X #:G0001), X
But what are those values? For that we need to look at the syntax of the documentation:
Syntax:
get-setf-expansion place &optional environment
⇒ vars, vals, store-vars, writer-form, reader-form
Arguments and Values:
place—a place.
environment—an environment object.
vars, vals, store-vars, writer-form, reader-form—a setf expansion.
Those five return values are described in 5.1.1.2 Setf Expansions:
List of temporary variables a list of symbols naming temporary variables to be bound sequentially, as if by let*, to values resulting
from value forms.
List of value forms a list of forms (typically, subforms of the place) which when evaluated yield the values to which the
corresponding temporary variables should be bound.
List of store variables a list of symbols naming temporary store variables which are to hold the new values that will be assigned to
the place.
Storing form a form which can reference both the temporary and the store variables, and which changes the value of the place and
guarantees to return as its values the values of the store variables,
which are the correct values for setf to return.
Accessing form a form which can reference the temporary variables, and which returns the value of the place.
So what do those values in the example mean?
(get-setf-expansion 'x)
;⇒ NIL, NIL, (#:G0001), (SETQ X #:G0001), X
To write to variable x, we don't need any temporary storage, and since there are no temporary values, we don't need any forms to produce values for them. We can notice here that the first and second values are always lists, and they should always have the same length. The third value is a list of store variables. This is a list, because we can actually use setf to modify multiple values, but in this case there's just one. The variables here are where the macro should actually store the new values for the place. Then, it's the writer-form (setq x #:g0001) that will actually take care of putting the value in the place. x, of course, is a simple way of reading the value.
As a more complex example, have a look at this transcript from SBCL:
CL-USER> (defstruct person
person-name)
;⇒ PERSON
CL-USER> (get-setf-expansion '(char (person-name (first (second list-of-list-of-persons))) 3))
; (#:TMP965)
; ((PERSON-NAME (FIRST (SECOND LIST-OF-LIST-OF-PERSONS))))
; (#:NEW964)
; (SB-KERNEL:%CHARSET #:TMP965 3 #:NEW964)
; (CHAR #:TMP965 3)
This means that if we wanted to change the fourth character of the name of the first person in the second list of persons in a list of lists of persons, we could do it with:
(let* ((temp965 (person-name (first (second list-of-list-of-persons))))
(old-char (char tmp965 3))) ; optional
(setq new964 <compute-new-value>)
(sb-kernel:%charset tmp965 3 new964))
We can compute the new value however we want (just fill in for <compute-new-value>), and we can even reference the old value if we want to (by including the optional line). All we need to do is set new964 to the new value, and then execute the writer-form that was given to us.
There are more examples of get-setf-expansion on Stack Overflow:
what is to append as push is to cons, in Lisp?
Writing a destructive macro or function like incf?
Writing a ++ macro in Common Lisp
How could I implement the push macro?
The scoping in Lisp is new to me and I think I've got it figured out, but the one area that confuses me a bit is how to mutate a global variable in a function without mentioning it specifically:
(defun empty-it (var)
"Remove everything from var."
(setf var nil))
Now, if I have *some-var* and call (empty-it *some-var*) it doesn't work, because the variables retains its contents from the scope prior to entering the function. Obviously, this works:
(defun empty-it-explicit ()
"Remove everything *some-var*."
(setf *some-var* nil))
Is it possible to have a general function that will clear the permanent contents of a stored variable, and have it work on any variable you pass to it? In other words, must you always explicitly mention a variable's name if you want it changed permanently?
(defun set-somevar-with-function (fn)
"Pass *some-var* into a function and set it to the results."
(setf *some-var* (funcall fn *some-var*)))
CL> (set-somevar-with-function #'empty-it)
Is this the correct Lisp idiom? If you had multiple vars you wanted to permanently mutate, would you have to write a separate function for each variable, each explicitly mentioning a different variable?
Basics
The scoping in Lisp is new to me and I think I've got it figured out,
but the one area that confuses me a bit is how to mutate a global
variable in a function without mentioning it specifically.
The scoping, aside from the availability of dynamically scoped variables, isn't really much different than what's available in other languages. E.g., in C, if you do something like:
void frob( int x ) {
x = 0;
}
int bar() {
int x = 3;
frob( x );
printf( "%d", x );
}
you'd expect to see 3 printed, not 0, because the x in frob and the x in bar are different variables. Modifying one doesn't change the value of the other. Now, in C you can take the address of a variable, and modify that variable through the pointer. You don't get pointers in Common Lisp, so you need something else if you want a layer of indirection. For lexical variables, you need to use closures for that purpose. For global variables (which are dynamically scoped), though, you can use the symbol that names the variable.
Direct modification of a variable (lexical or dynamic)
You can refer to global variables in the same way that you refer to any other variables in Common Lisp, by simply writing their name. You can modify them with setq or setf. E.g., you can do
(setq *x* 'new-value-of-x)
(setf *x* 'newer-value-of-x)
Indirect modification of a variable (dynamic only)
You can also take the symbol *x*, and use set or (setf symbol-value) to change the value:
(setf (symbol-value '*x*) 'newest-value-of-x)
(set '*x* 'newester-value-of-x)
Those cases give you some flexibility, because they mean that you can take the symbol as an argument, so you could do:
(defun set-somevar-with-function (var-name)
(setf (symbol-value var-name)
(funcall fn (symbol-value var-name))))
Understanding variable bindings (lexical and dynamic)
(Note: This is really just a rehashing of the C example above.) I think you understand why this bit of code that you posted doesn't work, but I want to mention a bit about it, just in case anyone with less experience comes across this question.
(defun empty-it (var)
"Remove everything from var."
(setf var nil))
Now, if I have *some-var* and call (empty-it *some-var*) it doesn't
work, because the variables retains its contents from the scope prior
to entering the function.
There's no unusual sense in which any variable is retaining or not retaining its value from one scope or another here. The evaluation model says that to evaluate (empty-it *some-var*), the system finds the function binding of empty-it and takes the value of *some-var*, let's call it x, and calls the function value of empty-it with the x. In doing that call, the variable var is bound to the value x. The call (setf var nil) modifies the variable var, and var has nothing to do with the variable *some-var*, except that for a while they happened to have the same value. Nothing here essentially depends on *some-var* being a global or dynamic variable, or on *some-var* and var having different names. You'd get the same results with another variable of the same name, e.g.:
(defun empty-it (var)
(setf var nil))
(let ((var 'value))
(empty-it var)
var)
;=> 'value
You'd even get the same if the parameter of empty-it were called *some-var*:
(defun empty-it (*some-var*)
(setf *some-var* nil))
(progn
(setf *some-var* 'value)
(empty-it *some-var*)
*some-var*)
;=> 'value
Beware of dynamic rebindings
Now, this will all work just fine if you're only modifying these variables, and you're never making new bindings for them. When you define a variable with defparameter or defvar, you're also globally proclaiming it special, i.e., dynamically scoped. The modifications done with set or setf are done to the most recent in scope binding of the variable. (When you modify a lexical variable, you're updating the innermost lexically enclosing binding.) This leads to results like the following:
(defparameter *x* 'first-value) ; AA
(defun call-and-modify (function name)
(setf (symbol-value name)
(funcall function
(symbol-value name))))
(progn
(let ((*x* 'second-value)) ; BB
(let ((*x* 'third-value)) ; CC
(print *x*) ; third-value (binding CC)
(call-and-modify (constantly 'fourth-value) '*x*)
(print *x*)) ; fourth-value (binding CC)
(print *x*)) ; second-value (binding BB)
(print *x*)) ; first-value (binding AA)
Symbols can be unbound with makunbound. Then the symbol is not just empty but gone. The danger, as always with mutation, is shared structure. hyperspec:makunbound
The symbol-function value of a symbol can be unbound with fmakunbound. hyperspec:fmakunbound
? (setf (symbol-value 'b) 42)
42
? (setf (symbol-function 'b)(lambda (x)(+ x 1)))
#<Anonymous Function #x210057DB6F>
? b
42
? (b 4)
5
? (fmakunbound 'b)
B
? b
42
? (b 4)
> Error: Undefined function B called with arguments (4) .
> ...[snipped]
> :pop
? b
42
? (makunbound 'b)
B
? b
> Error: Unbound variable: B
> ...[snipped]
> :pop
?
If you're looking for idiomatic lisp, I think (though I'm far from expert at lisp) the thing you want is to simply not have your function do the emptying. It can supply an empty value, just let that be it. So instead of having:
(defun empty-it (var)
(setf var nil))
; and then somewhere down the line calling:
(empty-it var)
You might do:
(defun empty ()
nil)
; and then somewhere down the line, call:
(setf var (empty))
Common-lisp is not limited to being (and maybe could be said simply not to be) a functional language, but for this, you'll want to take a (more) functional approach – meaning that your function may take a value, but it doesn't modify variables, it simply returns another value.
Of course, if your goal is to have the semantic expression of "make this thing empty", you could use a macro:
(defmacro empty-it (var)
`(setf ,var nil))
; and then, down the road, you can indeed call:
(empty-it var)
This would also be reasonably idiomatic.