(+ '(1 2 3 4 5) '(3 4 5 6 7))
Evaluate this expression. I don't know much about CLISP.
It returns an error when I runs it on CLISP.
Explain the reason for error ??
Thanks in advance
It's possible you were expecting this to concatenate
(+ '(1 2 3 4 5) '(3 4 5 6 7)) ==> '(1 2 3 4 5 3 4 5 6 7)
Common Lisp doesn't do this because it wouldn't make sense. In some languages like Python, there are a limited number of infix operators, so overloading + makes a certain amount of sense. However, in Common Lisp, there are infinitely many function names and + is but one of them, so we have different functions, such as append to do this.
It's also possible you were expecting this to add pointwise.
(+ '(1 2 3 4 5) '(3 4 5 6 7)) ==> '(4 6 8 10 12)
It doesn't do this as it's also against Lisp's philosophy. Adding elements pointwise like this is a feature of tacit languages such as APL or J. These languages go to a lot of trouble to get features like this to work in the most general possible cases. As such, they tend not to focus so much on certain other features, such as the object system or metaprogramming.
This is where Lisp shines: Lisp is a metaprogramming language, so rather than spend all their time developing corner cases for mathematical functions, they made a simple function that simply adds numbers together and does nothing more, and then spent the bulk of their development time making a good macro system. Common Lisp in particular adds to this by having one of the best object systems (with fully generic dispatch) that I've seen. Languages aren't good at everything, so the best languages have to define a philosophy and stick to it. Accepting all kinds of input simply isn't Lisp's philosophy; metaprogramming is.
CLISP itself will give you part of the answer:
[1]> (+ '(1 2 3 4 5) '(3 4 5 6 7))
*** - +: (1 2 3 4 5) is not a number
+ is a function that is only defined on numbers, so when the interpreter sees that a list of numbers has been offered as an argument to +, it can't go any further.
The interpreter sees (1 2 3 4 5) as the first argument to + after evaluating '(1 2 3 4 5), i.e. (quote (1 2 3 4 5)), which returns (1 2 3 4 5).
You may be thinking that + is more flexible, sort of like the way that it works in Javascript. No: It's just the math plus function.
(Why doesn't the interpreter complain about (3 4 5 6 7)? Because it stopped when it saw (1 2 3 4 5), and went to the debugger prompt.)
By the way, that error message is CLISP-specific, but any Common Lisp will give you an error on that input.
EDIT: Per #RainerJoswig's comment, it may be that the correct way to describe this is not that interpreter code responds to (1 2 3 4 5) being paired with +, but the + function code that does so, and doesn't bother with the second argument, etc. What I wrote was my best guess about the right way to describe the situation, and partially addresses OP's question, but I am not a Lisp internals expert.
Related
I would like a way to programmatically "deconstruct" a vector of variable-length vectors in Julia. I do not care about the resulting vector's order.
For example, suppose that my vector of vectors is A = [[1], [2,3], [4,5,6]]. I can deconstruct A by writing vcat(A[1], A[2], A[3]), which returns [1,2,3,4,5,6]. However, if the length of A is large, then this approach becomes cumbersome. Is there a better, more scalable way to obtain the same result?
Try Iterators.flatten:
julia> collect(Iterators.flatten(A))
6-element Vector{Int64}:
1
2
3
4
5
6
(This yields a lazy representation hence I collected this before showing the output)
While I would second Przemyslaw's answer for any situation where you can get away with using a lazy representation, maybe a more direct answer to your question is:
julia> vcat(A...)
6-element Vector{Int64}:
1
2
3
4
5
6
whenever you feel the need to type out all elements of a collection as function arguments, splatting ... is your friend.
Splatting can however negatively impact performance, so it is generally recommended to use reduce, which has a specialisation for vcat:
julia> reduce(vcat, A)
6-element Vector{Int64}:
1
2
3
4
5
6
I am not an english speaker, however I need to write code where I need to include print messages in English, hence using english terminology from Math, statistics etc.
This is the case:
I have two lists and I compare them, let's say:
list 1 - 1 2 3 4 5
list 2 - 2 4 6
So naturally when I compare both lists you see that 2 4 are present in both lists. What is the operation itself called? Because when I try to translate it from my language to english it's "section" or "cutting". I don't believe that this is the official mathematical term for this operation.
Also I want to know what is it called when you show the things that are missing in both lists. For example 1 3 5 6 ?
Thanks and sorry for the silly question.
Intersection for {1,2,3,4,5} ; {2,4,6} = {2,4}
Symmetric difference for {1,2,3,4,5} ; {2,4,6} = {1,3,5,6}
I'm reading Practical Common Lisp. In chapter 11, it says this about sorting:
Typically you won't care about the unsorted version of a sequence after you've sorted it, so it makes sense to allow SORT and STABLE-SORT to destroy the sequence in the course of sorting it. But it does mean you need to remember to write the following:
(setf my-sequence (sort my-sequence #'string<))
I tried the following code:
CL-USER> (defparameter *a* #( 8 4 3 9 5 9 2 3 9 2 9 4 3))
*A*
CL-USER> *a*
#(8 4 3 9 5 9 2 3 9 2 9 4 3)
CL-USER> (sort *a* #'<)
#(2 2 3 3 3 4 4 5 8 9 9 9 9)
CL-USER> *a*
#(2 2 3 3 3 4 4 5 8 9 9 9 9)
In this code we can see that the variable *a* has been changed by the sort function.
Then why do the book say that is necessary to do an assignment?
I'm using SBCL + Ubuntu 14.04 + Emacs + Slime
EDIT:
Following the comment of #Sylwester I add the evaluation of *a* so it's clear that the value has been changed.
It's necessary to do the assignment if you want your variable to contain the proper value of the sorted sequence afterwards. If you don't care about that and only want the return value of sort, you don't need an assignment.
There are two reasons for this. First, an implementation is allowed to use non-destructive copying to implement destructive operations. Secondly, destructive operations on lists can permute the conses such that the value passed into the operation no longer points to the first cons of the sequence.
Here's an example of the second problem (run under SBCL):
(let ((xs (list 4 3 2 1)))
(sort xs '<)
xs)
=> (4)
If we add the assignment:
(let ((xs (list 4 3 2 1)))
(setf xs (sort xs '<))
xs)
=> (1 2 3 4)
The variable can't be changed by the sort function, since the sort function does not know about the variable at all.
All the sort function gets is a vector or a list, but not variables.
In Common Lisp the sort function can be destructive. When it gets a vector for sorting, it can return the same vector or a new one. This is up to the implementation. In one implementation it might return the same vector and in another one it may return a new one. But in any case they will be sorted.
If there is a variable, which points to a sequence and for which the author expects that it will after sorting point to a sorted sequence: set the variable to the result of the sort operation. Otherwise there might be cases, where after potentially destructive sorting, the variable won't point to the SORT result, but still to an unsorted, or otherwise changed, sequence. In case of the vector this CAN be the old and unsorted vector.
REMEMBER
The only thing you can be sure: the SORT function returns a sorted sequence as its value.
When I do :
(grid:subgrid #( 1 2 3 4) '(1) '(2))
, i get 3. But when I do:
(grid:subgrid #( 1 2 3 4) '(1) '(* 2 1))
,i get the following error:
#<TYPE-ERROR expected-type: LIST datum: 2>.
Does anyone have a hint?
Apologies; not sure exactly where you're headed, and I don't know what the "grid" package is, so I couldn't test very much.
It looks like you're trying to determine grid coordinates on the fly with '(* 2 1) but it's not working. If that's what you are doing, you could maybe use a backquote comma construct...
(grid:subgrid #(1 2 3 4) '(1) `(,(* 2 1)))
subgrid seems to want args 2 and 3 (rest?) as lists with numbers for elements, and as originally provided, you were sending it the * symbol, which may explain why you were getting a type error.
If this is grid grid from Antik then subgrid parameters for the dimensions are lists
This is the manual. If you use slime just do M-. to look at the function.
Hope that helps
We stumbled upon an issue in our code today, and couldn't answer this Clojure question:
Does Clojure evaluate impure code (or calls to Java code) strictly or lazily?
It seems that side-effects + lazy sequences can lead to strange behavior.
Here's what we know that led to the question:
Clojure has lazy sequences:
user=> (take 5 (range)) ; (range) returns an infinite list
(0 1 2 3 4)
And Clojure has side-effects and impure functions:
user=> (def value (println 5))
5 ; 5 is printed out to screen
user=> value
nil ; 'value' is assigned nil
Also, Clojure can make calls to Java objects, which may include side-effects.
However, side-effects may interact poorly with lazy evaluation:
user=> (def my-seq (map #(do (println %) %) (range)))
#'user/my-seq
user=> (take 5 my-seq)
(0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
0 1 2 3 4)
So it returned the first 5 elements, but printed the first 31!
I assume the same kinds of problems could occur if calling side-effecting methods on Java objects. This could make it really hard to reason about code and figure out what's going to happen.
Ancillary questions:
Is it up to the programmer to watch out for and prevent such situations? (Yes?)
Besides sequences, does Clojure perform strict evaluation? (Yes?)
Clojure's lazy seqs chunk about 30 items so the little overhead is further reduced. It's not the purist's choice but a practical one. Consult "The Joy of Clojure" for an ordinary solution to realize one element at time.
Lazy seqs aren't a perfect match for impure functions for the reason you encountered.
Clojure will also evaluate strictly, but with macros things are a bit different. Builtins such as if will naturally hold evaluating.
Lazy constructs are evaluated more or less whenever is convenient for the implementation no matter what's referenced in them. So, yes, it's up to the programmer to be careful and force realization of lazy seqs when needed.
I have no idea what you mean by strict evaluation.