I am having a problem in understanding how the with keyword works. In particular, I considered it to be same as a let statement but it does not follow.
For example, these two codes "should" print the same values but the first one gives (nil nil) while the latter works fine.
(loop for c in clauses
with p = (car c)
collect p)
(loop for c in clauses
collect (car c))
with is to create local auxiliary variables. They are initialized once before the loop started and thus would be identical to writing this:
(let ((p (car c))
(loop for c in clauses
collect p))
Except the fact that it seems c exists as nil at the same time (car c) i sdone. I think it's because loop creates all their variables in one go at the beginning like I created p here.
You are looking for for:
(loop
for c in clauses
for p = (car c)
collect p)
Why not do it with destructuring?:
(loop
for (p) in clauses
collect p)
One thing which helps to understand LOOP a bit better is that a LOOP has three different clause sections
(loop
; first a single optional NAME clause
; then zero or more variable clauses with WITH, INITIAL, FINALLY and/or FOR
; then zero or more main clauses with DO, RETURN, COLLECT, APPEND, SUM, NCONC, ...
)
One has to keep the order of these clause sections.
There are two ways to introduce variables: FOR and WITH. FOR updates the variable in each iteration and WITH will do it only once. You can write these clauses in any order within the correct section, but generally the WITH binding and its value will be created before the FOR variable will have a correct value - though not always.
LispWorks warns about your specific code:
CL-USER 6 > (loop for c in '((1) (2) (3))
with p = (car c)
collect p)
Warning: Local Variable Initialization clause
(the binding of P) follows iteration forms but will be evaluated before them.
(NIL NIL NIL)
Often
(loop for c in clauses
with p = (car c)
collect p)
will be implemented by something like this:
(...
(let ((c nil) ...)
(let ((p (car c))) ; your (CAR ...) form
; iteration code ...
)))
In this case you had some 'luck', since (car nil) happens to work and only the result is not what you expect - silently.
But this will create an error:
(loop for c in '((1) (2) (3))
with p = (1+ c) ; note the 1+ instead of CAR
collect p)
Here (1+ nil) won't work and will be an error, because the function 1+ accepts only numbers as arguments. You won't see an unexpected result, but an error.
Style Rules
Don't mix FOR and WITH clauses.
Write WITH clauses before FOR clauses.
Don't depend on implementation specific behaviour and effects.
Related
Is recursion the only way to write something like a for-loop in the Racket dialect sdp ("Schreibe dein Programm!"), in which "(for)" isn't a thing or is there a more "efficient" or simpler way to do so?
What would the closest equivalent to the C++ loop for(i = 0 , i < 100, i++) look like in Racket-sdp code?
How I did this up until now was:
(: my-loop (natural -> %a))
(define my-loop
(lambda (i)
(cond
[(< i 100) (my-loop (+ i 1))] ; <-- count up by one till 99 is reached
[else "done"] ; <-- end
)))
(my-loop 0)
EDIT:
It's more of a general question. If I were to write lets say a raket library which contains a general function, that might be used like this:
(for 0 (< i 100) (+ i 1) (func i))
in my programs which is a for-loop that runs with a given function as it's "body", would there be a way to implement this properly?
[Professor of the mentioned course here.]
Recursion indeed is the only way to express iterated computation in the Racket dialect we are pursuing. (Yes, that's by design.)
Still, higher-order functions (and recursion) provide all you need to create your own "loop-like control structures". Take the following HOF, for example, which models a repeat-until loop:
(: until ((%a -> boolean) (%a -> %a) %a -> %a))
(define until
(lambda (done? f x)
(if (done? x)
x
(until done? f (f x)))))
Note that the until function is tail-recursive. You can expect it to indeed behave like a loop at runtime — a clever compiler will even translate such a function using plain jump instructions. (We'll discuss the above in the upcoming Chapter 12.)
You can make a high-order for-loop.
Here is an simple example:
(define (for start end f)
(define (loop i)
(when (< i end)
(f i)
(loop (+ i 1))))
(loop start))
(for 0 10 (λ (i) (displayln i)))
You can make this more general if you use a next function instead of (+ i 1) and use a while-predicate? function instead of (< i end).
Sometime, I need to iterate $n$ times where $n$ is the number of elements in a list. Of course, I could write something like:
(loop for i from 0 below (list-length l)
do something)
But I like to write rather:
(loop for i from 0
for u in l ; unused 'u' variable
do something)
where the for u in l part is merely intended to stop the loop after $n$ iterations. But then I don't use the u variable, and the interpreter keeps complaining. Is there some way to handle this style of coding? Should I avoid it and use list-length instead?
(loop for i from 0
for NIL in l
do something)
NIL should do it.
The LOOP destructuring pattern can be empty and the rest list elements are ignored.
Additionally: In a LOOP destructuring pattern, NIL indicates that the variable is not used.
Try the repeat clause:
(loop repeat (length l) ...)
The argument expression of the repeat clause is required to be evaluated once.
One horrible hack to do this which does not involve any extra traversals and if you really need to use loop is:
(defun foo (l)
(loop for i upfrom 0
for u = l then (cdr u)
while (consp u)
collect i))
But probably Kaz's answer of (loop repeat (length l) ...) is fine in practice, if you must use loop.
In GNU CLISP 2.49.92, the following code:
(defvar i 1)
(defun g ()
(format T "g0:~d~%" i)
(setf i 2)
(format T "g1:~d~%" i))
(defun f ()
(setf i 3)
(format T "f0:~d~%" i)
(g)
(format T "f1:~d~%" i))
(f)
gives the following output:
f0:3
g0:3
g1:2
f1:2
NIL
Similarly, the following code in C:
#include <stdio.h>
static int i = 1;
int g (void) {
printf("g0:%d\n", i);
i = 2;
printf("g1:%d\n", i);
}
int f (void) {
i = 3;
printf("f0:%d\n", i);
g();
printf("f1:%d\n", i);
}
int main() {
f();
return 0;
}
gives the following output:
f0:3
g0:3
g1:2
f1:2
According the the documentation that I found, defvar creates a special variable that is dynamically scoped. On the other hand, C is a statically scoped language. And yet, the two pieces of code give the same output. What then is the difference between a Special Variable and a Global Variable?
The difference is that a special variable is dynamically scoped: any binding of that name is visible to any code that runs during the dynamic extent of that binding, whether or not that binding is lexically visible to the code.
In what follows I am skating over some things: see notes at the end for some hints as to what I've skated over.
It's important to understand the difference between a binding and an assignment, which is often confused in various languages (notably Python, but not really C):
used as a noun, a binding is an association between a name and a value;
used as a verb, binding a variable creates a new association between a name and a value;
an assignment of a variable modifies an existing binding, it modifies an association between a name and a value.
So, in C:
void g (void) {
int i; /* a binding */
int j = 2; /* a binding with an initial value */
i = 1; /* an assignment */
{
int i; /* a binding */
i = 3; /* an assignment to the inner binding of i */
j = 4; /* an assignment to the outer binding of j */
}
}
C calls bindings 'declarations'.
In Lisp (by which I will mean 'Common Lisp' here & below), bindings are created by a small number of primitive binding forms: functions bind their arguments, let establishes bindings and there are some other forms perhaps. Existing bindings are mutated by, ultimately, setq and some other operators perhaps: setf is a macro which expands to setq in simple cases.
C does not have dynamic bindings: if my g function called some function h then if h tried to refer to i it would either be an error or it would be referring to some global i.
But Lisp does have such bindings, although they are not used by default.
So if you take the default case, bindings work the same way as C (in fact, they don't, but the difference does not matter here):
(defun g ()
(let ((i) ;a binding (initial value will be NIL)
(j 2)) ;a binding with a initial value
(setf i 1) ;an assignment
(let ((i)) ;a binding
(setf i 3) ;an assignment to the inner binding of i
(setf j 4)))) ;an assignment to the outer binding of j
In this case you can tell, just by looking (which is what 'lexical' means) which bindings are visible, and which assignments mutate which bindings.
Something like this code would be an error (technically: is undefined behaviour, but I will call it 'an error'):
(defun g ()
(let ((i))
(h)))
(defun h ()
(setf i 3)) ;this is an error
It's an error because (assuming there's no global binding of i), h can't see the binding established by g and so cannot mutate it. This is not an error:
(defun g ()
(let ((i 2))
(h i)
i))
(defun h (i) ;binds i
(setf i 3)) ;mutates that binding
But calling g will return 2, not 3 because h is mutating the binding it creates, not the binding g created.
Dynamic bindings work very differently. The normal way to create them is to use defvar (or defparameter) which declares that a given name is 'globally special' which means that all bindings of that name are dynamic (which is also called 'special'). So consider this code:
;;; Declare *i* globally special and give it an initial value of 1
(defvar *i* 1)
(defun g ()
(let ((*i* 2)) ;dynamically bind *i* to 2
(h)))
(defun h ()
*i*) ;refer to the dynamic value of *i*
Calling g will return 2. And in this case:
;;; Declare *i* globally special and give it an initial value of 1
(defvar *i* 1)
(defun g ()
(let ((*i* 2)) ;dynamically bind *i* to 2
(h)
*i*))
(defun h ()
(setf *i* 4)) ;mutate the current dynamic binding of *i*
Calling g will return 4, because h has mutated the dynamic binding of *i* established by g. What will this return?
;;; Declare *i* globally special and give it an initial value of 1
(defvar *i* 1)
(defun g ()
(let ((*i* 2)) ;dynamically bind *i* to 2
(h))
*i*)
(defun h ()
(setf *i* 4)) ;mutate the current dynamic binding of *i*
Dynamic bindings are very useful where you want some dynamic state to be established for a computation. For instance imagine some system which deals with transactions of some kind. You might write this:
(defvar *current-transaction*)
(defun outer-thing (...)
(let ((*current-transaction* ...))
(inner-thing ...)))
(defun inner-thing (...)
...
refer to *current-transaction* ...)
Note that *current-transaction* is essentially a bit of 'ambient state': any code in the dynamic scope of a transaction can see it but you don't have to spend some fantastic amount of work to pass it down to all the code. And note also that you can't do this with globals: you might think that this will work:
(defun outer-thing (...)
(setf *current-transaction* ...)
(inner-thing)
(setf *current-transaction* nil))
And it will, superficially ... until you get an error which leaves *current-transaction* assigned to some bogus thing. Well you can deal with that in CL:
(defun outer-thing (...)
(setf *current-transaction* ...)
(unwind-protect
(inner-thing)
(setf *current-transaction* nil)))
The unwind-protect form will mean that *current-transaction* always gets assigned to nil on the way out, regardless of whether an error happened. And that seems to work even better ... until you start using multiple threads, at which point you die screaming, because now *current-transaction* is shared across all the threads and you're just doomed (see below): If you want dynamic bindings, you need dynamic bindings, and you can't, in fact, fake them up with assignments.
One important thing is that, because CL does not textually distinguish between operations on dynamic bindings and those on lexical bindings, it's important that there should be a convention about names, so when you read code you can understand it. For global dynamic variables, this convention is to surround the name with * characters: *foo* not foo. It's important to use this convention if you do not want to fall into a pit of confusion.
I hope that is enough both to understand what bindings are, how they differ from assignments, and what dynamic bindings are and why they're interesting.
Notes.
There are other lisps than Common Lisp of course. They have different rules (for instance, for a long time in elisp, all bindings were dynamic).
In CL and its relations, dynamic bindings are called 'special' bindings, and dynamic variables are therefore 'special variables'.
It is possible to have variables which are only local but are dynamically bound, although I have not talked about them.
Primitively, Common Lisp does not support variables which are both global and lexical: all the constructs which create global variables create global dynamic (or special) variables. However CL is powerful enough that it's pretty easy to simulate global lexicals if you wan them.
There is some dispute about what an assignment to an undeclared variable (one for which there is no apparent binding) should do, which I alluded to above. Some people claim this is OK: they are heretics and should be shunned. Of course they regard me as a heretic and think I should be shunned...
There is a subtlety about things like (defvar *foo*): this declares that *foo* is a dynamic variable, but doesn't give it an initial value: it is globally dynamic, but globally unbound.
Common Lisp does not define any kind of threading interface so, technically, how special variables work in the presence of threads is undefined. I'm sure that in practice all implementations which have multiple threads deal with special bindings as I've described above, because anything else would be awful. Some (perhaps all) implementations (maybe all) allow you to specify that new threads get a new set of bindings of some global variables but that doesn't alter any of this.
There will be other things I have missed.
In the case you're showing, you're setting an existing binding. Nothing surprising here. The interesting part is what happens when you let a special variable.
(defvar *i* 1)
(defun f ()
(format t "f0: ~a~%" *i*)
(let ((*i* (1+ *i*)))
(format t "f1: ~a~%" *i*)
(g)
(incf *i*)
(format t "f2: ~a~%" *i*))
(format t "f3: ~a~%" *i*))
(defun g ()
(incf *i*)
(format t "g: ~a~%" *i*))
(f)
which prints:
f0: 1
f1: 2
g: 3
f2: 4
f3: 1
The let of *i* creates a dynamic extent (because *i* was globally declared special by defvar).
I have the following function:
(defun transform-matrix (matrix)
(let ((res (map 'vector
(lambda (x)
(map 'vector
(lambda (ix)
(if ix
'(t 0) ; --> Problem happens here
0))
x))
matrix)))
res))
This function will accept a 2d matrix, in which each element can either be t or nil. Then it will transform t -> '(t 0) and nil -> 0.
The result array has one problem is every (t 0) cons now point to the same memory location. For example if i save the result array in res variable and do this:
(eq (aref (aref res 0) 0)
(aref (aref res 1) 1))
*Assume that res[0][0] and res[1][1] is the '(t, 0) nodes.
This will result in T. But do like this is result in nil:
(eq '(t 0) '(t 0))
Can i ask what happen with the transform-matrix that make created cons to point to the same memory location.
I test these codes on SBCL 2.0.0 Windows 64 Bit.
Thank you.
One way to see the problem here is to change your function to this:
(defun transform-matrix (matrix)
(let ((non-nil-value '(t 0))
(nil-value 0))
(map 'vector
(lambda (x)
(map 'vector
(lambda (ix)
(if ix non-nil-value nil-value))
x))
matrix)))
It should be clear that this code is functionally identical: both functions have a single occurrence of '(t 0): this one just gives it a name.
But now let's gut this function and consider this:
(defun ts ()
(let ((non-nil-value '(t 0)))
(eq non-nil-value non-nil-value)))
Well, certainly I would expect the result of calling this function to be t.
And that's why every element in your resulting nested vectors which isn't 0 is the same: because you only ever constructed one object.
If you want all of the objects in the returned value to be different objects (ie not to be identical), you need to construct a new object each time, for instance by:
(defun transform-matrix (matrix)
(let ((non-nil-template '(t 0)))
(map 'vector
(lambda (x)
(map 'vector
(lambda (ix)
(if ix (copy-list non-nil-template) 0))
x))
matrix)))
This will ensure that each non-zero element of the resulting object
is distinct;
can safely be mutated.
Neither of these were previously true.
For the case of (eq '(t 0) '(t 0)) you might expect that this must return nil. That is (I think definitely) the case in interpreted code. But for compiled code the answer is not so clear. At least for the file compiler, it's fairly clear that in fact this may return t. Section 3.2.4.4 of the spec says, in part
If two literal objects appearing in the source code for a single file processed with the file compiler are the identical, the corresponding objects in the compiled code must also be the identical. With the exception of symbols and packages, any two literal objects in code being processed by the file compiler may be coalesced if and only if they are similar; if they are either both symbols or both packages, they may only be coalesced if and only if they are identical.
And in (eq '(t 0) '(t 0)), there are two literal lists, which are similar, and which therefore may be coalesced by the file compiler.
As a general rule, if you want a mutable object, or an object which you need to be certain is not identical to any other object, you should construct it explicitly: it is never safe (or even legal) to mutate literal objects, and the rules on which objects can be coalesced are complex enough that it is generally just safer to construct the objects so you know what is happening.
As an aside is there a reason you are using nested vectors rather than a two-dimensional matrix?
Just to add to TFB:
Lisp does not copy its arguments in a function call. It passes references to it:
(let ((a '(1 2))) ; A is a reference to (1 2)
(foo a) ; calls FOO and the same (1 2) will be
; accessible via a new reference inside FOO
(setf (aref array 0) a)
(setf (aref array 1) a) ; this will make the array at 0 and 1
; reference the same list
)
If i use the quote version '(t 0) twice in the REPL i still can get two different cons.
That's because in the REPL you would need to enter '(t 0) twice and make sure that the Reader (the R in REPL) constructs new lists, which it usually does:
CL-USER > (eq (read) (read))
(0 1) (0 1)
NIL
Now the REPL reader:
CL-USER 6 > '(1 2)
(1 2) ; result
CL-USER 7 > '(1 2)
(1 2)
CL-USER 8 > (eq * **) ; comparing previous results
NIL
Each call to READ conses a fresh new lists.
Side note: There are actually also more advanced REPL readers, where one can reference already existing lists, like in the REPL of the McCLIM listener.
Firstly, note that your transform-matrix function contains exactly one instance of the '(t 0) syntax, whereas the expression you're testing at the REPL contains two instances: (eq '(t 0) '(t 0)).
Because that expression has two instances, it is is possible that those will be different objects. In fact, the Lisp implementation would have to go out of its way to turn them into one object, and it is something that is allowed.
The (t 0) syntax is a piece of the program's source code. A program can apply the quote operator (for which the ' character is a shorthand) to a piece of its syntax to use that syntax as a literal. A given literal is one object; multiple evaluations of the same quote yield the same object.
When Lisp is naively interpreted, the interpreter recursively walks the original list-based source code. The implementation of the quote operator simply returns the piece of code that is being walked as a value.
When Lisp is compiled, the list-based source code is transformed to something else, such as native machine language for the CPU to execute directly. In the transformed image, the source code is gone. Yet, the compiler has to recognize the quote special form and translate it somehow. To do that, it has to take the piece of source code structure enclosed by quote and embed that object in the compiled image, so that it's somehow available to the compiled code: i.e. that quoted part of the source is not gone, but is propagated into the translation. For instance, the compiled image may be accompanied by a static vector dedicated for storing literals. Whenever the compiler process a quote expression like '(t 0), it allocates the next available slot in that vector, like position 47 or whatever, and stick the object (t 0) into that slot. The compiled version of '(t 0) code will then access that slot 47 in the literal data vector, and it will do that every time it is executed, retrieving the same object each time, just like the interpreted version of the program retrieveds the same piece of its own source code each time.
When compiling literals, the compiler may also search through the vector and de-duplicate it. Instead of allocating the next available index, like 47, it might scan through the literals and discover that index 13 already has a (t 0). Then it generates code to access index 13. Therefore, the compiled version of (eq '(t 0) '(t 0)) may well yield true.
Now, the way your question is framed, there is no evidence that there is an actual problem from all of the slots sharing a single instance of (t 0).
You need these objects to be different if you ever change the 0 value to something else by mutation. However, even that issue can be solved without actually making the objects different up-front. So that is to say, we can keep all the (t 0) entries objects pointing to the same object, and if we want to change some of them to, say, (t 3), we can allocate a whole new object at that time, rather that doing (set (cadr entry) 3). Moreover, maybe we can make all the (t 3) entries point to a single (t 3), like we did with (t 0).
It is impossible to say that changing '(t 0) to (list t 0) is the best approach to fix the problem, assuming there even is a problem.
I'm trying to wrap my head around Elisp's cl-loop facility but can't seem to find a way to skip elements. Here's an artificial example to illustrate the problem: I'd like to loop over a list of integers and get a new list in which all odd integers from the original list are squared. The even integers should be omitted.
According to the documentation of cl-loop, I should be able to do this:
(loop for i in '(1 2 3)
if (evenp i)
append (list)
else
for x = (* x x)
and append (list x))
The desired output is '(1 9) instead I get an error:
cl--parse-loop-clause: Expected a `for' preposition, found (list x)
Apparently the and doesn't work as expected but I don't understand why. (I'm aware that I could simplify the else block to consist of only one clause such that the and isn't needed anymore. However, I'm interested in situations where you really have to connect several clauses with and.)
Second part of the question: Ideally, I would be able to write this:
(loop for i in '(1 2 3)
if (evenp i)
continue
for x = (* x x)
append (list x))
Continue is a very common way to skip iterations in other languages. Why doesn't cl-loop have a continue operator? Is there a simple way to skip elements that I overlooked (simpler than what I tried in the first example)?
In Common Lisp it is not possible to write such a LOOP. See the LOOP Syntax.
There is a set of variable clauses on the top. But you can't use one like FOR later in the main clause. So in an IF clause you can't use FOR. If you want to introduce a local variable, then you need to introduce it at the top as a WITH clause and set it later in the body.
(loop for i in '(1 2 3)
with x
if (evenp i)
append (list)
else
do (setf x (* i i))
and append (list x))
LOOP in Common Lisp also has no continue feature. One would use a conditional clause.
Note, that Common Lisp has a more advanced iteration construct as a library ITERATE. It does not exist for Emacs Lisp, though.
You could do:
(loop for i in '(1 2 3)
if (oddp i) collect (* i i))
That would solve your sample problem.
And here's another without loop (yes, I know you asked for loop):
(let ((ns ()))
(dolist (n '(1 2 3))
(when (oddp n) (push (* n n) ns)))
(nreverse ns))
And without even cl-lib (which defines oddp):
(let ((ns ()))
(dolist (n '(1 2 3))
(unless (zerop (mod n 2)) (push (* n n) ns)))
(nreverse ns))
Everything about such definitions is clear -- just Lisp. Same with #abo-abo's examples.
loop is a separate language. Its purpose is to express common iteration scenarios, and for that it can do a good job. But Lisp it is not. ;-) It is a domain-specific language for expressing iteration. And it lets you make use of Lisp sexps, fortunately.
(Think of the Unix find command -- similar. It's very handy, but it's another language unto itself.)
[No flames, please. Yes, I know that dolist and all the rest are essentially no different from loop -- neither more nor less Lisp. But they are lispier than loop. Almost anything is lispier than loop.]
Here's a loop solution:
(loop for i in '(1 2 3)
when (oddp i) collect (* i i))
Here's a functional solution:
(delq nil
(mapcar (lambda(x) (and (oddp x) (* x x)))
'(1 2 3)))
Here's a slightly different solution (be careful with mapcan - it's destructive):
(mapcan (lambda(x) (and (oddp x) (list (* x x))))
'(1 2 3))