In a previous post, someone shows that you can express any number in elisp because it switchs over to big_nums automatically.
But when I call (setq long_max (expt 2 60)), I get
1152921504606846976
And when I call (setq long_max (expt 2 61)), I get
-2305843009213693952
And when I call (setq long_max (expt 2 62)), I get
0
What gives? I found that the numbers from the link above, 32768 32768, get me 0 as well. Why am I not getting the same sized integers. For context, I am using Spacemacs with Org-Mode
Thanks!
Emacs Lisp does not have bignums by default, as answered here: bignum in emacs/elisp (which also references the powerful calc packages).
The wrap-around behavior you see is because computation is made using modular arithmetic: see https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html#Integer-Basics.
actually in the post you mentioned Why in LISP , there is no limitation for number?, answer given by #Kaz is what you are looking for.
(search for "Emacs Lisp packs integers into")
Related
I just started learning Lisp. One of the first concepts to grasp seems to be the prefix notation (i.e. instead of writing "1 + 2", write "+ 1 2"). So I am trying to work out why the 1+ function exists.
What is the reason to prefer (+ 1 2) or (1+ 2)?
Is it just syntactic sugar? Is it for code optimisation? Is it for readability?
Perhaps there are more complex function call examples that show why the 1+ function exists. Any insight would be appreciated.
Common Lisp the Language:
These are included primarily for compatibility with MacLisp and Lisp Machine Lisp. Some programmers prefer always to write (+ x 1) and (- x 1) instead of (1+ x) and (1- x).
Actually this goes back to the early Lisp. Lisp 1.5 from 1962 has it already. There the functions were called ADD1 and SUB1.
Do remember that part of Common Lisp was standardizing what many implementations already had. So, if many implementations already had a 1+ function, that could have been enough to include it. Rainer's answer quotes CLtL2 on which implementations had it (MacLisp and Lisp Machine Lisp). But why would those implementations have had it in the first place? It's useful in loops, e.g.,
(do ((x 0 (1+ x)))
((= x 10))
; ...
)
That's a place where (+ x 1) would have been fine, too. But there are lots of cases where it's handy to call that kind of function indirectly, and it's easier to (mapcar '1+ …) than to (mapcar (lambda (x) (+ 1 x)) …).
But that's really about it. Adding one (or subtracting one; there's 1- as well) to something is just such a common operation that it's handy to have a function to do it. If there's hardware support, it might be something the implementation can optimize, too. (Although the documentation does note that "implementors are encouraged to make the performance of [(1+ number) and (+ 1 number)] be the same.") Since these functions are available and widely used, they're a very good way to indicate the intent. E.g., you could make a typo and write (+ 1 x) when you meant to write (+ 2 x), but it's much less likely that you wanted to add two if you actually wrote (1+ x). These functions are idiomatic in Common Lisp (e.g., see How do I increment or decrement a number in Common Lisp?). Emacs Lisp also includes 1+ and 1-.
The language wouldn't suffer greatly if it weren't there, but it would be reimplemented many times by many different people. For instance, Racket implements add1 and sub1. (Also, see add1 function from scheme to R5RS.)
While learning Lisp, I've seen that if there are two parameters to a function, where one is a single element or a subset (needle), and the other is a list (haystack), the element or subset always comes first.
Examples:
(member 3 '(3 1 4 1 5))
(assoc 'jane '((jane doe)
(john doe)))
(subsetp '(a e) '(a e i o u))
To me, it seems as if there was a rule in Lisp that functions should follow this guidance: Part first, entire thing second.
Is this finding actually based on a guideline in Lisp, or is it accidentally?
Functions like member and assoc are at least from 1960.
I would simply expect that it followed mathematical notation, for example in set theory:
e ∈ m
Since Lisp uses prefix notation, the predicate/function/operator comes first, the element second and the set is third:
(∈ e m)
John McCarthy had a Ph.D. in Mathematics.
Generally it is also more useful in Common Lisp to have set-like argument last:
(defun find-symbol (name package) ...)
The actual definition in Common Lisp is:
(defun find-symbol (name &optional (package *package*)) ...)
This allows us to use the current package as a useful default.
Lets see. The first McCarthy LISP from 1960 had the list sometimes as the first argument. See page 123 in this LISP manual. E.g.
;; 1960 maplist
(defun maplist (list function)
...)
Now this is perhaps because this function was one of the first higher order functions that were made. In fact it predated the first implementation as it was in the first Lisp paper. In the same manual on page 125 you'll find sassoc and it looks very much like assoc today:
(defun sassoc (needle haystack default-function)
...)
Both of these look the same in the next version 1.5 of the language. (See page 63 for maplist and 60 for sassoc)
From here to Common Lisp there are divergent paths that joins again. A lot of new ideas came about but there has to be a reason to break compatibility to actually do it. I can think of one reason and that is support for multiple lists. In Common Lisp maplist is:
(defun maplist (function &rest lists+)
...)
A quick search in the CLHS for common argument names in "wrong" order gave me fill, map-into, and sort. There might be more.
Peter Norvigs style guide say to follow conventions but not more detailed than that. When reading Scheme SRFIs they often mention defacto implementations around and what Common Lisp has as solution before suggesting something similar as a standard. I do the same when choosing how to implement things.
This question already has answers here:
Why do some people use keywords for the clauses in the loop macro?
(3 answers)
Closed 8 years ago.
I just saw the answer of Sylwester to this question, and I thought strange that the loop has colons everywhere.
Usually, I would write
(loop for n below 10 do (princ n) (terpri))
instead of
(loop :for n :below 10 :do (princ n) (terpri))
After some tests, I see that with the first loop, the symbols for, below and do are then part of cl-user (edit : actually not do, only the other two, probably because do is also a macro in the cl package), not with the second. Likewise, a 'X alone will then be part of cl-user, not ':X. The symbol-package function tells me the latter is in the keyword package.
Now, the first loop, without colons, looks much prettier to me, so I would like to know if the preceding remarks are a good reason to use the second one instead. That the symbols become "included" in the current package looks rather inoffensive, but maybe I have overlooked the consequences.
Any idea?
You moslty already answered your own question, the difference is as you described. :some-symbol will be in :KEYWORD package, and 'SOME-SYMBOL will be in your current package CL-USER by default. In loop macro it's just a matter of taste. Some people prefer to use :for notation to get better syntax highlighting in their text editor, for example.
CL-USER 23 > (find-symbol "LOOP" "CL")
LOOP
:EXTERNAL
CL-USER 24 > (find-symbol "FOR" "CL")
NIL
NIL
LOOP is a symbol in the COMMON-LISP package and it is exported. FOR is neither. Thus in every package which does not have a FOR symbol and does not inherit one, one will add such a symbol when writing a LOOP FOR loop.
That's it. Usually that should be no problem...
I'm learning Lisp from the book 'Practical Common Lisp'. At one point, I'm supposed to enter the following bit of code:
[1] (remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9 10))
(2 4 6 8 10)
I suppose the idea here is of course that remove-if-not wants a function that can return either T or NIL when an argument is provided to it, and this function is then applied to all symbols in the list, returning a list containing only those symbols where it returned NIL.
However, if I now write the following code in CLISP:
[2] (remove-if-not 'evenp '(1 2 3 4 5 6 7 8 9 10)
(2 4 6 8 10)
It still works! So my question is, does it even matter whether I use sharp-quote notation, or is just using the quote sufficient? It now seems like the additional sharp is only there to let the programmer know that "Hey, this is a function, not just some random symbol!" - but if it has any other use, I'd love to know about it.
I use GNU CLISP 2.49 (2010-07-07, sheesh that's actually pretty old).
Sharp-quote and quote do not have the same behaviour in the general case:
(defun test () 'red)
(flet ((test () 'green))
(list (funcall 'test)
(funcall #'test))) => (red green)
Calling a quoted symbol will use the function value of the quoted symbol (ie, the result of symbol-function). Calling a sharp-quoted symbol will use the value established by the lexical binding, if any, of the symbol. In the admittedly common case that there is no lexical binding the behaviour will be the same. That's what you are seeing.
You should get into the habit of using sharp-quote. Ignoring function bindings is probably not what you want, and may be confusing to anybody trying to understand your code.
This is not CLISP specific, it works in every Common Lisp implementation (I use Clozure Common Lisp here).
What happens is that if you give a symbol as a function designator then the implementation will look up the symbol-function (assuming the symbol is available in the global environment) for you:
? #'evenp
#<Compiled-function EVENP #x3000000F2D4F>
? (symbol-function 'evenp)
#<Compiled-function EVENP #x3000000F2D4F>
In general you can use either, but there's an interesting effect if you rebind the called function later. If you specify the function (#' or (function)) then the calls will still call the old function because the lookup has been done at compile time; if you use the symbol then you will call the new function because the lookup is re-done at runtime. Note that this may be implementation-specific.
As you have noticed (or read) funcall et. al. are will make an effort to convert the function argument you provide into something approprate. So as you have noticed they will take a symbol and then fetch the symbol-function of that symbol; if that works out they will then invoke that.
Recall that #'X is converted at readtime into (symbol-function x) and 'x into (quote x). It's good practice to have the symbol-function work done at compile time.
But why? Well two trival reasons it is slightly faster and it signals that you don't intend to redefine F's symbol-function after compile time. Another reason is that in a recent Pew Research study 98.3% of Lisp developers prefer it, and 62.3% will shun those that don't do this.
But there's more.
'(lambda (..) ...) is quite different v.s. #'(lambda (..) ...). The first is very likely to end up using eval, i.e. it will be slow. The first runs in a different scope v.s. the second one, i.e. only the second one can see the lexical scope it appears in.
I tried using ctrl-c then :a
But It doesn't work here.
My code is like:
(defun game-repl()
(loop (print (eval (read)))))
then I run
(game-repl())
look()
(require 'cl)
(loop (setq x (read))
(if (eq x 'exit)
(return)
(print (eval x))))
Emacs modes often send an interruption signal to the inferior program only when you hit Ctrl-C twice in a row (i.e., the key sequence you are looking for is C-c C-c). In particular, this is true for SLIME.
This is because C-c is a prefix key that is usually combined with other keys to access a whole bunch of mode-specific features.
This question can refer to:
how to programmatically break out of a loop that would otherwise be infinite or
how to manually stop an infinite loop that's already raging.
The 1st has satisfactorily been answered by #fred-foo (and it seems it was OP's actual question). The 2nd has been tackled by #matthias-benkard but his answer is not working for emacs lisp.
The actual answer to manually stop a running infinite emacs-lisp loop is Ctrl+g (C-g in emacs-speak).
There is a documentation page in the emacs lisp manual on this very topic.
Sorry, I don't have the reputation to just amend #matthias-benkard's answer and the question ranks high on search engines...
[Reference http://www.psg.com/~dlamkins/sl/chapter05.html]
Most of the time you write a LOOP form, you'd like to have a way out. Fortunately, a RETURN form anywhere inside will cause control to leave the LOOP; any value you specify becomes the value of the LOOP form:
? (loop
(print "Here I am.")
(return 17)
(print "I never got here."))
"Here I am."
17
RETURN is normally used in a conditional form, like this:
? (let ((n 0))
(loop
(when (> n 10) (return))
(print n) (print (* n n))
(incf n)))
0 0
1 1
2 4
3 9
4 16
5 25
6 36
7 49
8 64
9 81
10 100
NIL
?
This Stack Exchange answer is the first hit on google for "break a never ending loop slime"
C-c C-b
What is missing, is that different lisps handle this break differently. I found this answer because GNU Clisp just doesn't intercept SLIME's C-c C-b. Nor does it do what SBCL does which is intercept both C-c C-b and C-c C-c.