I have noticed that when I type an operator in REPL, it is often expanded into a value which has something to do with the input/output history.
Specifically I noticed that:
+, ++ ... expand to previous inputs,
*, ** ... expand to previous outputs,
- expand to the current input
There apparently are more (/ expands to something but I haven't figured it out exactly).
I've tried browsing the clisp docs, but unsuccessfully.
My questions:
What such magic REPL variables are also there? What do they do?
Is there a way to access Nth input or output (like IPython's In and Out arrays)?
The REPL variables are documented in the environment dictionary of the Hyperspec (search for "Variable"). The standard does not require holding any more of input/outputs than three, and I am not aware of any implementation that does it.
As mentioned in the other answer, these variables are documented in the ANSI Common Lisp standard.
In addition to that a Common Lisp implementation may have lots of other features. A full featured top-level with user interface is often called a 'Lisp listener'.
The CLISP implementation provides additional commands in the debugger. See chapter 25 of its documentation.
LispWorks has some extensions in the REPL and also provides a Listener. Here are some examples:
Interaction number 2, in the CL-USER package:
CL-USER 2 > (* 3 4)
12
The same, but we can omit the outer parentheses:
CL-USER 3 > * 3 4
12
Let's redo interaction 2:
CL-USER 4 > :redo 2
(* 3 4)
12
Let's redo interaction 2, but with division instead of multiplication:
CL-USER 5 > :use / * 2
(/ 3 4)
3/4
Other implementations with extensions like commands, output histories, or similar features are for example Allegro CL and Clozure CL.
SLIME, which provides a Common Lisp development environment based on GNU Emacs, also provides an extended REPL.
Related
I love Racket's #;. I want to see it in every language that I ever use again. Can it be added to other Lisps via their macro systems? Or does the commenting character break the macro system's ability to read the code?
A sufficient answer will demonstrate a macro being built in any Lisp other than Racket that allows for a change in the commenting system. You need not actually implement Racket's #;, but I would like it if you do. Lisps with the least similarity to Racket, e.g. Clojure or any non-Scheme will be particularity nice to see.
#; isn't a macro, it's what Common lisp would call a readmacro: what it does is defined at read time, not later than that. Read macros which aim to completely suppress input are mildly perilous because there needs to be a way of saying 'read the following thing, but ignore it', and that's only possible if any other readmacros behave well: there's nothing to stop someone defining a readmacro which produces some side-effect even if reading is suppressed.
However, well-behaved readmacros (which includes all of the standard ones and the rest of the standard reader) in CL won't do that: they'll listen to whether reading is being suppressed, and behave accordingly.
CL allows you to do this as standard by using its conditionalisation on features, and in particular #+(or) <expr> will always skip <expr>.
But you can define your own: #; is not predefined so you can define it:
(set-dispatch-macro-character
#\# #\;
(lambda (stream char n)
(declare (ignore char))
(let ((*read-suppress* t))
(dotimes (i (or n 1) (values))
(read stream)))))
After this, or at least with a better tested version of this, then #; <expr> (or obviously #;<expr>) will read as whitespace, and #2; ... ... will skip two following expressions:
> (let ((x #;1 #2; 2 3 4)) x)
4
What you are looking for is #+(or) reader macro.
Since (or) evaluates to nil, the condition is always false the following form is never evaluated.
This question already has answers here:
operator #+ and #- in .sbclrc
(2 answers)
Closed 6 years ago.
I am reading the cl-fad/load.lisp code tonight, and I found there are symbols #+: and #-: in the front of expression or string.
What's these symbols meaning?
These are a read-time conditionalization facility: #+ and #- let you decide what expression to read based on Feature Expressions.
E.g.,
#+:allegro (require :osi)
#+:sbcl (require :sb-executable)
means that when running under allegro, the module :osi will be loaded but when running under sbcl, the module :sb-executable will be loaded by require.
Under all other implementations require will not be called at all because read will skip over the forms.
You can check not just the implementation name, but a specific feature, e.g.,
#+(<= (integer-length most-positive-fixnum) 32)
code for a 32-bit lisp
#+(> (integer-length most-positive-fixnum) 32)
code for a 64-bit lisp
In addition to selecting code based on implementation, this allows one to easily "comment out" a section of your code (i.e., the next sexp):
#+(or) (this code will be skipped over by any lisp reader
because (or) returns nil)
This are reader macros based on the list features, this macros indicates to execute a form or not if the symbol is present on the features list
Showing the features list:
CL-USER> *features*
(:SWANK :QUICKLISP :QUICKLISP-SUPPORT-HTTPS :ROS.INIT :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-MACOSX :OS-UNIX :ASDF-UNICODE :PRIMARY-CLASSES :COMMON-LISP :OPENMCL :CCL :CCL-1.2 :CCL-1.3 :CCL-1.4 :CCL-1.5 :CCL-1.6 :CCL-1.7 :CCL-1.8 :CCL-1.9 :CCL-1.10 :CCL-1.11 :CLOZURE :CLOZURE-COMMON-LISP :ANSI-CL :UNIX :OPENMCL-UNICODE-STRINGS :IPV6 :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :OPENMCL-PRIVATE-HASH-TABLES :STATIC-CONSES-SHOULD-WORK-WITH-EGC-IN-CCL :X86-64 :X86_64 :X86-TARGET :X86-HOST :X8664-TARGET :X8664-HOST :DARWIN-HOST :DARWIN-TARGET :DARWINX86-TARGET :DARWINX8664-TARGET :DARWINX8664-HOST :64-BIT-TARGET :64-BIT-HOST :DARWIN :LITTLE-ENDIAN-TARGET :LITTLE-ENDIAN-HOST)
In my case I 'm running:
CL-USER> (lisp-implementation-type)
"Clozure Common Lisp"
CL-USER> (lisp-implementation-version)
"Version 1.11-r16635 (DarwinX8664)"
Let's execute the form if I'm using CCL
CL-USER> #+CCL (1+ 1)
2
It works, because I have CCL on the features list
CL-USER> #-CCL (1+ 1)
; No value
It doest work because I have CCL in the features list
Or you can think the oppsite,only execute if I dont' have in teh features list
CL-USER> #-calimero (1+ 1)
2
You can ad any symbol :word to the features list and you can also add logic
let's execute if I'm on the CCL and using a darwin host (i.e MAC OS X)
CL-USER> #+(and ccl darwin-host) (1+ 1)
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.
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'm writing an emacs major mode for a programming environment which supports two slightly different programming languages. Both are lisps (one is Scheme), so both use s-expressions. The two languages are differentiated by their function definition keyword: scheme uses define, while the other language (which is called xtlang) uses bind-func
So, in the same buffer, I have
(define foo ; this is scheme
(lambda (a)
(+ scheme-fn a))
(bind-func bar ; this is xtlang
(lambda (b)
(* xtlang-fn b))
I've got the font-locking working, using something like
(font-lock-add-keywords nil
'(("(\\(define\\)\\>"
(1 font-lock-keyword-face))
("(\\(bind-func\\)\\>"
(1 font-lock-keyword-face))
("\\<scheme-fn\\>"
(0 font-lock-function-name-face))
("\\<xtlang-fn\\>"
(0 font-lock-function-name-face))
))
What I'd like to be able to do is to be able to colour the parens differently based on the language (scheme/xtlang).
So, colour all the parens in the form red if the top-level defun is a define, and blue if it's a bind-func, while still highlighting all the keywords/functions within the forms as normal.
This may require multi-line font locking, since the define/bind-func will probably be on a previous line to the keywords to be highlighted. This thread suggests that font-lock-multiline in conjunction with match-anchored in font-lock-keywords may be the answer, but then goes on to suggest that font-lock-multiline should only be used in situations where the multi-line aspect is the exception rather than the rule.
My other option seems to be to use syntax-propertize, but I'm a bit confused about how that works - the documentation is a bit sparse.
The easiest way to handle this is utilizing the following fact:
MATCHER can be either the regexp to search for, or the function name
to call to make the search (called with one argument, the limit of the
search;
In other words, you could replace regexps like "\\<scheme-fn\\>" with a function that repeatedly search for the regexp using re-search-forward, and return if a match is found in the correct context.
For a concrete example of a package that use this technique, look at cwarn-mode, which is part of the standard Emacs distribution.