So I was writing my own function and I called it make-list and I got this from debugger:
The function MAKE-LIST is predefined in Clozure CL.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [CONTINUE] Replace the definition of MAKE-LIST.
Fine, but what if I had accidentally chosen option 0?? Would my compiler be broken and forever have the wrong definition of an internal function, as I would have replaced it?
Only your currently running image would be broken, in which case you can restart CCL to restore it.
The only way to do permanent damage is to save the image, and chose to overwrite the original image file.
Many Lisp systems are written in Lisp themselves.
Clozure CL is such an example. Clozure CL is written in Clozure CL (with some C and assembler). Clozure CL can compile itself.
Thus many/most Common Lisp functions in Clozure CL are written in Clozure CL. So it needs some kind of a switch, where it allows to define or redefine built-in functionality. So there is definitely a way to edit the implementation's source code and change things. It would be best that your definitions are 'correct', so that the functioning of the Lisp system is not compromised. Keep in mind that redefinitions typically do not have an effect on inlined functions or on already expanded macros.
Now, if we as typical programmers use Clozure CL, some packages are protected and redefining the symbols are not allowed and an error is signaled. But you can continue and then change internal functions. As always in many Common Lisp, they are wide open for changes, but this comes with the responsibility for you as the programmer to do the right thing.
If you change a Lisp-internal function, there a some ways to leave permanent damage:
saving an image and using that later
using it to recompile CCL itself or parts of it
you could compile a file and somehow the generated code could be different than with the original compiler
you could compile a file and somehow the generated code includes an inlined version of the changed Lisp function
if one loads such a file, it could be automatically via some init file, it contains the changes and the changed code will be a part of the then currently running Lisp.
Related
I noticed some people using the terms as if they were synonoms.
For instance, in the same scenario, I heard "add this function to the lisp image evaluating it" and "eval this function into the Lisp interpreter to use it later".
However, I am not sure the use is technically precise. Thus, the question.
These are two orthogonal concepts. Let’s start from the usually comprehensive Common Lisp Glossary:
Lisp image n. a running instantiation of a Common Lisp implementation. A Lisp image is characterized by a single address space in which any object can directly refer to any another in conformance with this specification, and by a single, common, global environment.
So the key idea is that an image is a set of mutually referring Lisp objects (functions and data) that can be “called” or “accessed” during the execution of a program.
The way in which a Common Lisp program is executed depends instead from the way in which a system is implemented. It could be executed by compilation in machine language, for instance, or through some form of interpretation (or even a mix of the two). So a Lisp interpreter is just a particular way in which an implementation is done (and in the current Common Lisp systems there are many different ways to implement the language).
Image
"Image" is a file on disk.
"Add a function to the image"
means evaluate the function and save the image, so the function if immediately available on the next invocation.
REPL
"Interpreter" is (usually) a wrong level of abstraction; one should use
"REPL" instead. E.g., SBCL does not have an interpreter at all (everything is always compiled) but this is not a detail that is relevant to this topic.
"eval this function into the Lisp interpreter to use it later"
means evaluate the function in the current REPL and use it in the same process (i.e., it is available until Lisp is restarted).
An image is a copy of a Lisp heap written to disk (or another secondary storage). The Lisp heap is the memory for data storage in RAM of a computer. To write a Lisp heap to an image, the running Lisp is stopped and the memory is dumped to disk. Then the Lisp is either resumed or quit.
The image can be used to restore the heap upon starting a new Lisp. That's usually faster than starting a fresh Lisp and then loading the corresponding software.
A Lisp interpreter is a program which executes Lisp programs from source. Many Lisp implementations don't use an interpreter, but they execute compiled Lisp code, typically Lisp code compiled to native machine code.
I am interested in creating an emacs extension that delegates the work to an external program.
I have my logic as a library, however, written in Common Lisp. If I can directly call the CL library from Elisp, that would be simpler for me; otherwise, I can use a client/server architecture.
I have looked into emacs LSP implementation, but I couldn't find a simple entry on how to do it.
You could build a binary of your CL app and call it from the Elisp side. It seems to suit you fine, so here are more pointers:
How to build a Common Lisp executable
short answer: see https://lispcookbook.github.io/cl-cookbook/scripting.html
Building a binary is done by calling sb-ext:save-lisp-and-die from the terminal (and not from a running image). Note that this function name changes on the different implementations.
ASDF has a directive that allows to do it declaratively, and portably (for all implementations). You add 3 lines in your .asd file and you mention what is your program's entry point. For example:
;; myprogram.asd
:build-operation "program-op" ;; leave this as is.
:build-pathname "myprogram"
:entry-point "myprogram::main" ;; up to you to write main.
Now, call (asdf:make :myprogram).
See a more complete example in the Cookboo.
Call it from Elisp
See https://wikemacs.org/wiki/Emacs_Lisp_Cookbook#Processes
This returns the output as a string:
(shell-command-to-string "seq 8 12 | sort")
Full documentation: https://www.gnu.org/software/emacs/manual/html_node/elisp/Synchronous-Processes.html
Other approaches
Other approaches are discussed here: https://www.reddit.com/r/lisp/comments/kce20l/what_is_the_best_way_to_call_common_lisp_inside/
For example, one could start a lisp process with Slime and execute CL code with slime-eval.
In C, if I want to see a function that how to work, I open the library which provides the function and analyze the code. How can be implementations of the lisp functions seen? For example, intersection function
You can also look at the source code of lisp functions.
For example, the source files for CLISP, one Common Lisp implementation, are available here: http://www.clisp.org/impnotes/src-files.html
If you want to examine the implementation of functions related to lists, you can look at the file: http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/src/list.d
The usual answer is "M-."
Assuming you have a properly configured IDE, and the source code of the function, clicking on its name and pressing M-. (that's Meta, or Alt or Option or Escape, and dot/period; or whatever key your IDE uses) should reveal its definition (or, for a generic function, definitions, plural; including any compiler macros that might optimize out some cases). Sometimes it's on a right-click or other mouse menu or toolbar.
If the source isn't available, you can often see the actual compiled form by evaluating (disassemble 'function)
Most IDE's, including perennial favourite Emacs+Slime, have other Inspection operations on the menu as well.
In a non-IDE environment, most compilers have reflection tools of their own (compiler-dependant) which are usually also mapped by the Swank library that Slime uses; one might find useful function in that package.
And this really should be documented in your IDE's manual.
I should postscript this that:
You really shouldn't care about the implementation of the core library functions; their contractual behavior is very well documented in the CLHS standard, which is available online and eg, Quicklisp has an utility to link it to Slime (C-c C-d h on a symbol in the COMMON-LISP package); for all well-written Lisp libraries, there should be documentation attached to functions, variables, classes, etc. accessible via the documentation function in the REPL or the IDE's menus and Inspection windows.
Core library functions are often highly optimized and far more complex than most user-level code should want to be, and often call down into compiler-specific "guts" that one should avoid doing in application code.
I am byte-compiling a module. It gives me this warning:
Warning: cl package required at runtime
Why is this a warning? I am well aware that I am using the cl package. In fact there is a (require 'cl) statement in the module.
Is there something wrong with using the cl stuff?
If so, is there a list of published workarounds? The main things I use are mapcan and delete-duplicates.
The reason of this warning is a GNU policy which does not want a package cl to be used in Elisp. But it would be foolish as well to prohibit it completely. So they decided to show a warning.
You can find more information here
Just in case someone reads this on his quest for proper use of cl: The methods described here are now deprecated.
As least as of emacs 24, instead of cl you should use cl-lib or, if the macros suffice, cl-macs. These are new versions of cl that work with a clean namespace. E.g. instead of defun* you have cl-defun.
The old cl-package now is only for backward-compatibility and shouldn't be used in new code.
There are namespace clashes between Elisp and Common Lisp but the cl package gets round them by appending an asterisk to the repeated names. For instance it implements the Common Lisp version of defun but calls it defun*. The upshot is that there are no namespaces clashes between cl and Elisp and it is quite safe to (require 'cl).
If you want to get rid of the silly warning, customize the variable byte-compiler-warnings.[1] This will turn off the warning when you compile the code. If you distribute the code the warning will probably came back when someone else compiles it. If you don't want this to happen use the code:
(with-no-warnings
(require 'cl))
You can stop the byte compiler warning about any Lisp form in a similar way.[2] It's probably a not good idea in general, but you may be able to justify it in this case.
The code:
(eval-when-compile
(require 'cl))
will get rid of the warning, but you will only be able to use the macros from the package if you do this. Macros are evaluated at compile time and Elisp does not need to know about them at run time. If you only use the macros from any package, not just cl, then it is a good idea to use eval-when-compile as it will stop unnecessary packages loading at run time, both saving memory and making the code faster. But it seems to me that it's a misuse of the function to use it just to avoid a warning. And, of course, if you do want to use any of the functions from cl, you can't use eval-when-compile anyway.
[1] You may need to add (require 'bytecomp) to your .emacs file to get access to this variable.
[2] In theory, anyway, but there's a bug in with-no-warnings that means it doesn't supress some warnings about lexical variables.
Common Lisp has lots of namespace clashes with elisp, often the functions seem to do the same thing, but differ in some subtle detail. Mixing the two is a risk that is best not done behind the user's back. For this reason, most of the more useful functions in cl.el are defined as macros, so that cl.el can be required at compile time only, and the macros will then only affect the code that uses them in future sessions of Emacs.
I wasn't able to suppress this message after reading the comments before mine.
However, I received the following instruction from a kind person on the GNU emacs mailing list:
Require cl-lib, and then change the call to use cl-remove-if-not,
instead of remove-if-not.
Which proved to be the remedy.
In sum: by 'requiring cl-lib, one must also change the name of the function/macro call.
HTH....
I'm an experienced C++/.NET/Java Windows/web programmer trying to learn (Common) Lisp. I'm reading Practical Common Lisp and using SLIME.
I'm getting the Lisp language easily enough, but I'm having trouble groking the mechanics of development. One of my issues is dealing with Emacs. I have no experience with it and find it generally confusing with hard to find/figure out commands.
Specific questions:
I get the REPL, but I don't quite get how I can use it effectively. When I need to change a function I have to retype the defun and make changes (tedious and error prone). How can I do this better?
How do I get from entering code at the REPL to actually having a program? I'm used to the C model where you have code files that you can review, edit and recompile. I know Lisp has something similar (via the load function), but how does one get a function I just defined and tested into a file to be saved? I'm hoping there's a better method than my current select+copy+paste.
How do you debug errors? Is there any ability to step into code like I would with other languages?
As long as the S-expression is valid, I don't get any errors when entering a (defun ...). It's not until I try to use it that I find out it's not valid. Is there any way to get errors sooner (i.e. compile the code)?
Is there some IDE that would be more familiar to me or allow me to play with the language easier?
Should I switch to learning Scheme instead?
Any tips would be greatly appreciated!
-I get the REPL, but don't quite get how I can use it effectively. When I
need to change a function I have to
retype the defun and make changes
(tedious and error prone). How can I
do this better?
-How do I get from entering code at the REPL to actually having a program?
I'm used to the C model where you have
code files that you can review, edit
and recompile. I know lisp has
something similar (via the load
function), but how does one get a
function I just defined and tested
into a file to be saved? I'm hoping
there's a better method than my
current select+copy+paste.
Load SLIME. Enter code in your .lisp file, and then run slime-eval-buffer to load all your code into Lisp. Then, for a specific function you are hacking on C-e, C-j to redefine it in your running Lisp.
-How do you debug errors? Is there any ability to step into code like I would with other languages?
Yes. (trace 'my-function) - or some variant on that - and when my-function is called, it will break into the debugger.
-As long as the S-expression is valid, I don't get any errors when entering a
(defun ...). It's not until I try to
use it that I find out it's not valid.
Is there any way to get errors sooner
(i.e. compile the code)?
To some degree, that is a characteristic of dynamic languages (Python, Perl, Ruby, Lisp, etc.). Try SBCL for better error-checking.
-Is there some IDE that would be more familiar to me or allow me to play with the language easier?
Emacs is the free IDE for Lisp. Allegro has a free edition I believe; I've never tried it though..
-Should I switch to learning Scheme instead?
Nah, Scheme is not as pragmatic a language.
I'm an experienced C++/.NET/Java Windows/Web programmer trying to learn (Common) Lisp. I'm reading Practical Common Lisp and using SLIME.
One can also use the LispWorks Personal Edition for learning Lisp. It has some limitations and the full product is commercial, but it is quite a bit easier to use.
I get the REPL, but don't quite get how I can use it effectively. When I need to change a function I have to retype the defun and make changes (tedious and error prone). How can I do this better?
The REPL has a history. With keyboard commands you can get back prior input and change it. Other than that just edit a Lisp file and compile code from there. In Lisp you can compile/eval individual expressions and definitions. Typical IDEs like SLIME, LispWorks or Allegro CL allow you to run code also from normal Lisp text windows - additionally to executing expressions in the REPLA (aka Listener).
How do I get from entering code at the REPL to actually having a program? I'm used to the C model where you have code files that you can review, edit and recompile. I know Lisp has something similar (via the load function), but how does one get a function I just defined and tested into a file to be saved? I'm hoping there's a better method than my current select+copy+paste.
Copy and paste in one thing. But the correct way is to work from a text file in an editor window. One can compile/load expressions, the editor buffer or the associated file.
How do you debug errors? Is there any ability to step into code like I would with other languages?
See STEP, TRACE and related. SLIME, LispWorks and Allegro CL have lots of additional features.
As long as the S-expression is valid, I don't get any errors when entering a (defun ...). It's not until I try to use it that I find out it's not valid. Is there any way to get errors sooner (i.e. compile the code)?
For many cases one uses a compiler. The compiler will find a range of errors and also will note when something is unusual (for example a function does not exist or a variable has not been defined).
-Is there some IDE that would be more familiar to me or allow me to play with the language easier?
LispWorks, Allegro CL are the best under Windows. There are some alternatives like Corman Lisp (I don't know it is maintained right now) or even Ufasoft Lisp.
Should I switch to learning Scheme instead?
Not really.
It doesn't sound like you're really using SLIME, or at least not in the way it was intended to be used. ("have to retype the defun", "the C model where you have code files")
I recommend watching some SLIME screencasts (or, even better, watching a Lisp programmer use SLIME for a few minutes, if you have one handy). The SLIME webpage has a couple.
It sounds like you'd really enjoy the DrRacket IDE. Racket is closer to Scheme than to Common Lisp, but you could dip your toes into the Lisp family without the speed bump of the Emacs style of development.