Avoiding strange results with most comparison operators with read-from-string - common-lisp

I am using an implementation of common lisp called CCL and I have run into a strange issue that I do not quite understand.
When I call:
(read-from-string "(=)")
I get a list containing the equal operator:
(=)
But when I call:
(read-from-string "(<)")
I get a backslash in front of the <:
(\<)
I find this quite confusing and I am wondering if this may be specific to my implementation or is this an intended part of the spec? Why would this \ show for < and > but not =?
Is there anyway to avoid the backslash?

The backslash is just a presentation issue.
When you do (mapcar #'symbol-name (read-from-string "(<)")) you probably get ("<"), so you are getting the right symbol.
If you want, you can report this as a bug to the CCL maintainers, since this backslash is a (minor) deviation from the ANSI CL standard.

Related

SBCL Compiler Diagnostic Messages (missing with a "when" with no body)

By accident, I recently came across a latent coding error in one of my functions, dealing with a when statement. A reduced paraphrase might look like:
(defparameter a 0)
(when (or (= a 0)
(= a 1)
(* a a)))
The problem is a misplaced parenthesis, so it actually is
(when (or (= a 0)
(= a 1)
(* a a)))
In a situation like this, wouldn't it be useful for the compiler to generate either a style warning or note? It seems to me that the meaning of a when statement normally implies a condition and a body, even though the body is strictly optional. Of course, a print pretty would have caught this in the editor, but I had copied it from elsewhere. Is there a reason that SBCL does not check for these kinds of mistakes?
a print pretty would have caught this in the editor
To discuss the options, I know about:
trivial-formatter will format the source code.
(trivial-formatter:fmt :your-system :supersede)
cl-indentify indents the source code. Has a command line utility. I tried it once and it was not bad, but different than Emacs' indentation, thus annoying for me.
$ cl-indentify bar.lisp
It links to lispindent but I was less happy with its result.
However, the best would be to not only format the code and re-read it ourselves, but to
run checks against a set of rules to warn against code smells
This is what proposes the lisp-critic. It can critique a function or a file. However:
(edit) it doesn't really have a Slime integration, we have to either critique a function or a whole file.
if you feel adventurous, see an utility of mine here. It could be an easier way to test snippets that you enter at the REPL.
it hasn't the rule about when without a body (we can easily add it)
And it would be best that the run failed with an error status code if it found a code smell. Again, a little project of mine in beta tries to do that, see here. It doesn't have much rules now, but I just pushed a check for this. You can call the script:
$colisper.sh tests/playground.lisp
it shows an error (but doesn't write it in-place by default):
|;; when with no body
|(when (or (= a 0)
| (= a 1)
!| (* a a))
!| (error "colisper found a 'when' with a missing body. (we should error the script without this rewrite!)"))
and returns with an exit code, so we can use it has a git hook or on a CI pipeline.
The problem is that if a human writes (when x) (or whatever that expands into, perhaps (if x (progn) nil)) this is probably a mistake, but when a program writes it it may well not be: it may be just some edge case that the program hasn't been smart enough to optimize completely away. And a huge amount of code that the compiler processes is written by programs, not humans.

Clisp error message: an object cannot start with #\). What does this mean?

Please see this example. I am using GNU CLISP 2.49.
(defparameter *pudding-eater* 'henry')
;; output:
READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> #<IO TERMINAL-STREAM>>: an
object cannot start with #\)
(defparameter *pudding-eater* 'henry)
;; output:
*PUDDING-EATER*
I do understand that it is the double quotes that are causing the problem. What I do not understand is that, what does an object cannot start with #\) mean? Where did I start with #\)? I was expecting some error message like umatched parenthesis.
Your extra quote character after 'henry is the start of another object, which would make sense in a context like:
(defparameter *pudding-eater* 'henry '(a b c))
(if defparameter took that many arguments, anyway)
But, the next character after your quote is a close-paren. The Common Lisp notation for displaying a character (rather than a symbol, string, etc) is a #\ prefix, followed by the character.
So, the error message is not saying anything about the \ or # characters, only ), and it's telling you you have one where it expected more expressions instead of the end of the current one (because you started an expression by adding that ' character).
As other answers pointed out, #\( is the syntax to represent the ( character. See section 2.4.8 Sharpsign. First the reader sees #, then dispatches on the next character, \ (backslash) which is used to read character objects. Your error message is thus saying that ) was unexpected in your input.
Error message
I was expecting some error message like umatched parenthesis.
This is basically what the error is saying, and other implementations like SBCL produce the message you expect. I am working from Emacs:
CL-USER> )
... enters the debugger with unmatched close parenthesis and a backtrace.
Let's see why. Using GET-MACRO-CHARACTER, we ask our Common Lisp implementation to return the function associated with the #\) character:
CL-USER> (get-macro-character #\))
SB-IMPL::READ-RIGHT-PAREN
NIL
In Emacs, the resulting value is a shown as a presentation, which allows us to inspect it. You can also point the name of the function, and if your installation of SBCL allows it (e.g. you installed from source), you can go to the definition with M-.:
(defun read-right-paren (stream ignore)
(declare (ignore ignore))
(simple-reader-error stream "unmatched close parenthesis"))
The same with CLISP produces the error you see. We can also do:
CL-USER> (get-macro-character #\))
#<SYSTEM-FUNCTION SYSTEM::RPAR-READER>
NIL
However the source definition for that system function is not so clear (if you are curious see the non-official mirror), but it is not surprising that another error message is displayed.
The read-table and how Lisp reads lists of expressions
The behavior depends on which functions is bound in the current readtable to the character being read.
All implementations signal an error in that case, because when you reach a point where you have to lookup into the readtable for a closing parenthesis, the input is necessarily badly formed. It is the job of a function like READ-DELIMITED-LIST, called from the function associated with the opening parenthesis, a.k.a. #\(, to read until it find the corresponding closing parenthesis. Note that if you look-up the reader for #\( in SBCL, it does not use read-delimited-list, but a different, specialized version. It is a little bit too long to post it here.
Quote and recursive reading
In your case, you also have quote. How does quote behave?
(defun read-quote (stream ignore)
(declare (ignore ignore))
(list 'quote (read stream t nil t)))
It builds a list starting with quote and containing a sub-expression obtained by calling READ recursively. This is just as above, when I entered a closing parenthesis at the REPL prompt. Since we are not currently in the context of an open parenthesis, we encounter the #\) character, look it up in the readtable and signal an error.
You write
'henry')
' is a terminating macro char in Common Lisp.
Terminating means:
if it appears while parsing a token, it terminates that token.
So the second quote character terminates the token before, here henry.
We have: quote, henry, quote, closing parenthesis.
The quote character is a macro character, which specifically causes another object to be read. 'some-object is read as (QUOTE some-object). some-object can be any data: a number, a string, a list, a symbol, ...
Thus a new object is being read and textual representations of objects can not start with a closed parenthesis. Closed parentheses are used to end lists or cons cells.
If you wanted a closing parenthesis in a symbol, you would need to escape it:
CL-USER 3 > '\)
\)
CL-USER 4 > '|)|
\)
CL-USER 5 > '|)woaaah(|
|)woaaah(|

Strange autocompletion result in emacs + common lisp

I am using Emacs with SLIME for my development environment. When I type (write-to and then C-M-i I get the following autocompletions:
Click on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
write-to-sting
write-to-string
I know Common Lisp is powerful, but I guess write-to-sting is not in the ANSI standard. Google didn't offer a single hit for this function. Then I tried to find it in the SBCL code, but alas
(documentation 'write-to-sting 'function) returns nil so it doesn't have a documentation string.
When I try to execute the function (write-to-sting) I get The function COMMON-LISP-USER::WRITE-TO-STING is undefined.
Apropos also finds an unbound function:
(apropos 'write-to)
WRITE-TO
WRITE-TO-STING
WRITE-TO-STRING (fbound)
My question is: What is going on? Does anyone knows the story behind this function?
At some point during your interaction with the Lisp environment, you wrote write-to-sting and it was read by the Lisp reader. The symbol was interned in the COMMON-LISP-USER package. After all, maybe you intended to implement a function that sends an email to Sting, who knows?
Auto-completion works by filtering the currently known symbols in the environment.
You can safely (unintern 'write-to-sting) (or implement it).

What's the meaning of "#+" in the code of cl-mysql? [duplicate]

This question already has answers here:
operator #+ and #- in .sbclrc
(2 answers)
Closed 6 years ago.
Recently I tried to read code about cl-mysql, but got stuck with the #+.
Tried to google it, but not work, so turn to here
(defun make-lock (name)
#+sb-thread (sb-thread:make-mutex :name name)
#+ecl (mp:make-lock :name name)
#+armedbear (ext:make-thread-lock)
#+ (and clisp mt) (mt:make-mutex :name name)
#+allegro (mp:make-process-lock :name name))
And looks like it is for different backend lisp compiler. But still no idea why write something like this.
Anyone can help me make it clear, thx.
#+ is a reader-macro that checks if a keyword is in the special variable *FEATURES*. If it isn't there, the following form will be skipped over (by the reader; the compiler will never see it). There is also #- which does the opposite.
There are some things that aren't part of the Common Lisp standard, but are important enough that all (or most) implementations provide a non-standard extension for them. When you want to use them in code that needs to work on multiple implementations, you have to use read-time conditionals to provide the correct code for the current implementation. Mutexes (and threads in general) are one of those things.
Of course there may be features provided by third party libraries as well. The contents of *FEATURES* will look something like this:
(:SWANK :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF-PACKAGE-SYSTEM :ASDF3.1
:ASDF3 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :64-BIT
:64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
:C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS
:COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
:FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS
:INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS :LARGEFILE :LINKAGE-TABLE :LINUX
:LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-DLADDR
:OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL
:OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES
:PRECISE-ARG-COUNT-ERROR :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX
:SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST
:SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES
:STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
:STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
:UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
So if you wanted to write code that depends on Quicklisp for example, you could use #+quicklisp. If you wanted code that is only run if Quicklisp is not available, you'd use #-quicklisp.
You can also use a boolean expression of features. For example,
#+(or sbcl ecl) (format t "Foo!")
would print Foo! on either SBCL or ECL.
#+(and sbcl quicklisp) (format t "Bar!")
would only print Bar! on SBCL that has Quicklisp available.
One could imagine that we can write:
(defun make-lock (name)
(cond ((member :sb-thread *features)
(sb-thread:make-mutex :name name))
((member :ecl *features*)
(mp:make-lock :name name))
...))
But that does usually not work, because we can't read symbols when their package is not existing and some packages are implementation/library/application specific. Packages are not created at read time in a lazy/automatic fashion.
In Common Lisp, reading a symbol of a package, which does not exist, leads to an error:
CL-USER 1 > (read-from-string "foo:bar")
Error: Reader cannot find package FOO.
1 (continue) Create the FOO package.
2 Use another package instead of FOO.
3 Try finding package FOO again.
4 (abort) Return to level 0.
5 Return to top loop level 0.
In your example sb-thread:make-mutex is a symbol which makes sense in SBCL, but not in Allegro CL. Additionally the package SB-THREAD does not exist in Allegro CL. Thus Allegro CL needs to be protected from reading it. In this case, the symbol sb-thread:make-mutex will only be read, if the the feature sb-thread is present on the cl:*features* list. Which is likely only for SBCL, or a Lisp which claims to have sb-threads available.
The feature expressions here prevents the Lisp from trying to read symbols with unknown packages - the packages are unknown, because the respective software is not loaded or not available.

Emacs css-mode auto closing of braces and auto insertion of semi-colon after colon (ala Textmate)

I'm looking for a way to mimic Textmate's CSS editing behavior in Emacs.
In Textmate, when adding a CSS property:
#element {} <-- Braces auto close.
#element {background: ;} <-- after typing the colon, the semi-colon is automatically inserted and the cursor is placed between them.
I have taken a look at several css-modes (and textmate.el) but cannot see that anyone has implemented this.
I have absolutely zero knowledge of emacs-lisp would be be willing to give it a shot and write something myself, but does anyone know if this has been done already?
You want to look at some examples of electric functions (the naming convention used when additional input or formatting is performed when particular visible characters are typed).
There's nothing special about the implementation. The key in question is bound within the mode's keymap to a function which does the work. Aside from the fact that you must handle the insertion of the character typed, it's just like any other keybinding.
cc-mode has several examples. The basic approach looks like this:
(define-key c-mode-base-map "{" 'c-electric-brace)
(defun c-electric-brace (arg)
(interactive "*P")
;; [...]
(self-insert-command (prefix-numeric-value arg))
;; [...]
)
Admittedly c-electric-brace is a far more complicated function than you might be expecting, but it would be trivial to have a function which simply inserted the same number of }s after inserting the {s.
(defun my-electric-brace (arg)
"Automatically add a closing '}' for every '{' inserted."
(interactive "*P")
(let ((count (prefix-numeric-value arg)))
(self-insert-command count)
(save-excursion
(insert-char ?} count))))
(defun my-css-mode-hook ()
(local-set-key (kbd "{") 'my-electric-brace))
(add-hook 'css-mode-hook 'my-css-mode-hook)
You might find that is a little simplistic, and there are circumstances in which you don't want the matching brace to be inserted, however. You would probably also want to deal with automatically removing matching braces when you delete one of them, by defining electric delete functions.
Your electric colon requirement is also less trivial than the brace, as it should only occur in the right context (although in practice you might get away with a naive implementation, as I don't think you would be typing colons in a CSS file that were not in the correct context.)
Hopefully this points you in the right direction, if you decide to write your own solutions.
Obviously you would want to read some tutorials on elisp, but for understanding the code above, just note that you can use C-h f (describe-function) to read the documentation for any elisp function (or M-x find-function to view the code).
For general purpose autopairing of all sorts of braces, etc you might want to take a look at autopair-mode.

Resources