I get a "Undefined function FILE-EXISTS-P called with arguments ..." error when calling (file-exists-p "somepath") in Clozure Common Lisp but everywhere I look it appears that this function should be available. I even see it when using M-x apropos.
I'm using LispBox for Windows.
Does anyone have an idea of what might be wrong or maybe suggest a process by which I can try to figure it out?
FILE-EXISTS-P is not a standard Common Lisp function or a Clozure Common Lisp specific function.
Instead, you can use the standard PROBE-FILE function (see the manual) to check if a file exists:
CL-USER> (probe-file "not-existant-file.lisp")
NIL
CL-USER> (probe-file "/Users/myname/temp.lisp")
#P"/Users/myname/temp.lisp"
Note that the in the standard is undefined the result of applying the function to a directory, while the CCL implementation (at least on some systems) checks correctly also if a directory exists:
CL-USER> (probe-file "/Users/myname/")
#P"/Users/myname/"
Related
I'm trying to get a better understanding of how S-expressions are evaluated in different lisps and wanted to see they would handle interesting ill-formed expressions. I get that Common Lisp and Scheme are totally different languages, but is there a specific difference in their semantics that explains the difference in behavior. For example, Lisp-1s and Lisp-2s have observable differences in their behavior, as do hygienic vs non-hygienic macro systems.
I have a program containing an unreachable ill-formed if expression in Scheme and Common Lisp.
;; foo.scm
(if #t 1 (if))
(display "12")
And the Common Lisp version
;; foo.lisp
(if t 1 (if))
(display "12")
chicken and guile both produce a syntax error.
Chicken:
% chicken foo.scm
Syntax error: (foo.scm:1) in `if' - pair expected
(if)
Expansion history:
<syntax> (##core#begin (if #t 1 (if)))
<syntax> (if #t 1 (if))
<syntax> (##core#if #t 1 (if))
<syntax> (if) <--
Guile:
% guile foo.scm
...
.../foo.scm:1:9: source expression failed to match any pattern in form (if)
sbcl and clisp both print 12 and emit no warnings.
SBCL:
% sbcl --load foo.lisp
This is SBCL 1.3.11, an implementation of ANSI Common Lisp.
...
12
0]^D
CLISP
% clisp foo.lisp
"12"
Implementations of Common Lisp: Interpreter and Compilers
In Common Lisp the type of code execution depends on what the Lisp system implements and how you use it. Often Common Lisp implementations have multiple ways to execute code: an interpreter and one or more compilers. Even a single running implementation may have that and it will allow the user to switch between those.
Interpreter: executing directly from the Lisp data structure. It is not an interpreter of virtual machine code, like the JVM. One would not expect that the interpreter validates the full code tree/graph during execution. The interpreter usually looks only at the current top form it executes.
Compiler: compiles Lisp code to C, some Byte Code or Machine Code. Since the compiler generates code before the code runs, it will do a syntax check of all the code (for a possible exception, see the remark at the bottom) it sees.
Toplevel evaluation: may use an interpreter, a compiler or a mix of both.
GNU CLISP has both an interpreter and a compiler
Example in GNU CLISP:
LOAD of a text file typically uses the interpreter:
[1]> (load "test.lisp")
;; Loading file test.lisp ...
;; Loaded file test.lisp
T
The Interpreter will not detect the error, because it does not check the whole expression for syntactic correctness. Since the else clause with the syntax error is never used, the Interpreter will never look at it.
CLISP also has a compiler:
[2]> (compile-file "test.lisp")
;; Compiling file /tmp/test.lisp ...
** - Continuable Error
in #:|1 1 (IF T 1 ...)-1| in line 1 : Form too short, too few arguments: (IF)
If you continue (by typing 'continue'): Ignore the error and proceed
The following restarts are also available:
ABORT :R1 Abort main loop
As you see, the CLISP compiler detects the syntax error and gives a clear error message.
SBCL uses a compiler, but also has an interpreter
SBCL by default uses a compiler, which will detect the error. For top-level forms it uses for some forms a simpler evaluation mechanism. One can also switch to an interpreter.
If you write a simple IF form in SBCL, the evaluator does not use full compilation and doesn't catch the error:
CL-USER> (if t 1 (if))
1
If you write the same code inside a function definition, the error gets detected, because function definitions will be compiled by default:
CL-USER> (defun foo () (if t 1 (if)))
; in: DEFUN FOO
; (IF)
;
; caught ERROR:
; error while parsing arguments to special operator IF:
; too few elements in
; ()
; to satisfy lambda list
; (SB-C::TEST SB-C::THEN &OPTIONAL SB-C::ELSE):
; between 2 and 3 expected, but got 0
;
; compilation unit finished
; caught 1 ERROR condition
WARNING: redefining COMMON-LISP-USER::FOO in DEFUN
FOO
If you would switch to the full SBCL interpreter, the error would not be detected at definition time:
CL-USER> (setf *evaluator-mode* :interpret)
:INTERPRET
CL-USER> (defun foo () (if t 1 (if)))
WARNING: redefining COMMON-LISP-USER::FOO in DEFUN
FOO
Optimisation and syntax checking
Note that some optimising compilers might not check the syntax of unreachable code.
Summary
In most Common Lisp implementations you need to use the compiler to get full syntax warnings/errors.
Looks like the CL part is handled by nicely by Rainer. I just want to point out that R5RS are not required to act the way as your two implementations are.
R5RS is very underspecified and for if it only specifies what to do when used right we have this passage about error handling:
When speaking of an error situation, this report uses the phrase "an
error is signalled" to indicate that implementations must detect and
report the error. If such wording does not appear in the discussion
of an error, then implementations are not required to detect or report
the error, though they are encouraged to do so. An error situation
that implementations are not required to detect is usually referred to
simply as "an error."
So, to wrap this up in R5RS the string "banana" is just as correct as Guile and Chickens response to the evaluation of (if #t 1 (if)).
R6RS on the other hand states in general that when an exceptional situation is detected by the implementation, an exception is raised. This means that if with less than two expressions or more than 3 should raise an exception, but it doesn't say it has to happen compile time since the language might be parsing and interpreting as it goes.
When I enter this at the REPL prompt:
(setf (readtable-case *readtable*) :invert)
I get this error message:
Error in SETF [or a callee]: Cannot expand the SETF form (READTABLE-CASE
*READTABLE*).
Why do I get this error?
(format nil "~A ~A" (lisp-implementation-type) (lisp-implementation-version)) says "Kyoto Common Lisp GCL 2.6.2". The result of (eq 'readtable-case 'cl:readtable-case) is T. What does this all mean please?
The second expression means you're using the correct symbol. The first indicates which Lisp implementation you're using: That should be GNU Common Lisp 2.6.2
After some search I found this message on the gcl-devel list saying ...
The problem appears to be this line:
(setf (readtable-case *readtable*) readcase)
in randomly-check-readability. I'd recommend this as the next
ansi issue to resolve, since it's blocking the tests.
... with a subject line "ansi-tests in 2.7.0". The message is from 2004.
Bottom line: I guess you need a more recent or even* a different Lisp implementation.
(* as mentioned by Rainer Joswig the issue also affects the current 2.6.12 release)
I guess all major Lisp implementations support this. CLISP 2.49 does, SBCL and CCL probably do, as far as I know ECL does also.
I get this message when starting SLIME:
; loading #P"d:/lisp/slime-2.12/swank-loader.lisp"
STYLE-WARNING: redefining EMACS-INSPECT (#<SB-PCL:SYSTEM-CLASS T>) in DEFMETHOD
The REPL works normal.
I am totally new to EMACS and SLIME and I'd like to know what does this mean and how to fix it.
I use Windows 8 (64-bit), GNU Emacs 25.0.50.1 (x86_64-w64-mingw32), SLIME 2.12, and SBCL 1.2.7
I addressed folks in GitHub and jackcarrozzo replied
with this post:
Good question - it took a bit of spelunking to find a full answer. The short answer is that emacs-inspect stores handlers for inspecting objects; when a particular object is inspected, the relevant generic function (based on type) will match and be evaluated. From http://lisp-book.org/contents/chslime.pdf page 16, you can run this to see the currently-attached generics:
M-. swank-backend:emacs-inspect
That pdf also describes creating your own inspector as well as additional features that look pretty cool.
Regarding your second point: lots of stuff gets printed to the slime-events buffer; unless you're having a slime-specific issue, you probably don't need to even have it open in a window. Warnings and so forth relevant to your code and interactions will come out either directly in the REPL, in the inferior-lisp buffer, or in one of a few other buffers that emacs/slime will auto-open for you when needed.
CL-USER> (use-package :elk)
; Evaluation aborted on #<SB-KERNEL:SIMPLE-PACKAGE-ERROR "The name ~S does not designate any package." {1002C9D683}>.
CL-USER> (defun moose (a) (+ a 7))
MOOSE
CL-USER> (defun moose (a) (+ a 8))
STYLE-WARNING: redefining COMMON-LISP-USER::MOOSE in DEFUN
MOOSE
CL-USER>
So, in summary: don't worry about it. Slime makes interfacing Common Lisp in emacs simple, and it does a great job of staying out of the way. Slime does admittedly have a ton of features but it doesn't force you to use them. Note to self: I should really get around to learning them some day...
I want to write an Emacs Lisp function that will turn on flyspell-mode regardless of the current state of the mode. Function flyspell-mode-on is deprecated. The documentation suggests that a positive prefix argument will turn flyspell-mode, but unfortunately running
(flyspell-mode 1)
results in an error message:
Wrong number of arguments: (lambda (flyspell-mode 1)), 0
If I could figure out how to call flyspell-mode with a prefix argument, I believe I could solve this problem.
The most relevant section I can find in the Emacs Lisp manual is the section entitled "Interactive Call", which describes such commands as call-interactively. This is emphatically not what I want.
(The ultimate problem I am trying to solve is to create a mode hook that turns on the mode regardless of its current state.)
N.B. The title of the question emacs lisp call function with prefix argument programmatically makes it appear to be related, but that question was asking about how to create an interactive command, and the issue was ultimately resolved by using call-interactively.
EDIT: This question is moot; I have found an alternate solution to my original problem:
(add-hook 'text-mode-hook
(function (lambda ()
(require 'flyspell)
(if flyspell-mode nil (flyspell-mode)))))
But I would still like to know how to call an Emacs Lisp function with a prefix argument, from another Emacs Lisp function, with nothing interactive.
UPDATE: Perhaps I should have asked why I was getting that error message...
It looks like your version of Flyspell mode does not follow the minor mode conventions, which require that you can turn on a minor mode with (name-of-mode t) or any positive prefix argument, turn it off with (name-of-mode 0) any negative prefix argument, and toggle it with (name-of-mode nil).
If you have the latest version of Flyspell, a bug report might be in order. I have the version shipped with GNU Emacs 23.2 on my machine, and it respects the convention. My version also defines two functions turn-on-flyspell and turn-off-flyspell, both trivial wrappers around flyspell-mode; functions with such names are common, but not official conventions. The functions flyspell-mode-on and flyspell-mode-off are apparently intended for internal use.
As a general matter, commands read the current prefix argument from the current-prefix-arg variable. Don't confuse that with prefix-arg, which is the value for the next command (only a few commands like universal-argument touch this variable). Thus, if you need to pass a prefix argument when calling a function, bind or set current-prefix-arg.
(let ((current-prefix-arg t))
(flyspell-mode))
If you are not calling a function interactively, then the (interactive) declaration is not used to obtain the arguments.
In the vast majority of cases, you do not need to worry about whether an argument can be a "prefix argument" for non-interactive calls; just check the function documentation, and pass the value you need for whatever it is you want to do.
If for some reason you do need to replicate sending a prefix argument in a non-interactive context, you will need to check that function's (interactive) declaration and determine exactly how it is using that argument, and ensure that you replicate that behaviour for the argument you do pass.
For full details, see:
C-hf interactive RET
M-: (info "(elisp) Prefix Command Arguments") RET
In more complex cases where the function changes its behaviour based on the current-prefix-arg variable, you may be able to set that variable directly.
(let ((current-prefix-arg '(4)))
(foo current-prefix-arg))
I can think of this.. Should be more better
(call-interactively (lambda ()
(interactive)
(flyspell-mode '(4))))
UPDATE:
I can run this directly.. what am i missing from the question.?
(flyspell-mode '(4))
EDITED: Removed quote for lambda expression (I added this note because SX forces an edit to be at least six characters long, so this can be deleted).
FWIW, the `flyspell-mode' function has accepted an argument (as in "(flyspell-mode 1)") at least since Emacs-21, so I don't know how you got that error.
But while I'm here, I might as well point out that (add-hook 'text-mode-hook 'flyspell-mode) has changed meaning in Emacs-24: instead of meaning "toggle flyspell-mode in text modes" it will now mean "enable flyspell-mode in text modes". It's a backward-incompatible change, but I believe it will fix more latent bugs than it will introduce.
See my comment for the fix to the source of your problem. As for the answer to your question, the way the prefix arg is turned into some kind of Lisp argument depends on the interactive spec, so the only way to do it reliably (i.e. without prior knowledge such as the fact that it's a minor mode function) is to call the function interactively:
(let ((current-prefix-arg '(4)))
(call-interactively 'flyspell-mode))
I'm not Emacs and Elisp master (yet ;)) but I think in this case you may use Ctrl-u 1 Alt-x flyspell-mode.
Good day, when load any source file into editor i get following message:
File mode specification error: (wrong-type-argument stringp nil)
and flymake simply not working then.
Starting with --init-debug does not improve anythong. Any idea how to debug the cause of problem ?
This general error is thrown when a Lisp function actually expects a string argument but receives a nil.
Try setting (setq debug-on-error t) at the top of your .emacs to get a stack-trace showing you which string is nil. In case the error is caused by FlyMake settings in your .emacs: here is a good introduction.
The deeper reason for wrong-type-argument exceptions is that Lisp functions have no prototypes and cannot rely on the interpreter; they're always defined and hence need to parse their arguments on their own.
The Emacs Lisp interpreter itself does not perform type checking on
the actual arguments passed to functions when they are called. [...]
It is therefore up to the individual function to test whether each
actual argument belongs to a type that the function can use.
For more information see Type Predicates in the Emacs Lisp Reference Manual.