I want to read help for clisp function from REPL or just from shell.
I found (symbol-plist) function for this which give this:
(symbol-plist 'bit)
(SYSTEM::TYPE-SYMBOL #<COMPILED-FUNCTION SYSTEM::TYPE-SYMBOL-BIT>
SYSTEM::SETF-EXPANDER SYSTEM::STORE SYSTEM::DOC
(CLHS "Body/any_bit.html" SYSTEM::FILE
((DEFSETF #P"/build/buildd/clisp-2.49/debian/build/places.fas" 941 941))))
but it's not so useful info in order to understand how does (bit) works?
So are there any manuals and documentation for clisp function something like man in shell?
[7]> (describe 'bit)
BIT is the symbol BIT, lies in #<PACKAGE COMMON-LISP>, is accessible in 9 packages CLOS, COMMON-LISP, COMMON-LISP-USER, EXPORTING, EXT,
POSIX, REGEXP, SCREEN, SYSTEM, names a function, names a type, has 3 properties SYSTEM::TYPE-SYMBOL, SYSTEM::SETF-EXPANDER, SYSTEM::DOC.
ANSI-CL Documentation is at
"http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/any_bit.html"
For more information, evaluate (SYMBOL-PLIST 'BIT).
#<PACKAGE COMMON-LISP> is the package named COMMON-LISP. It has 2 nicknames LISP, CL.
It imports the external symbols of 1 package CLOS and exports 978 symbols to 8 packages REGEXP, POSIX, EXPORTING, SCREEN, CLOS,
COMMON-LISP-USER, EXT, SYSTEM.
#<SYSTEM-FUNCTION BIT> is a built-in system function.
Argument list: (#:ARG0 &REST SYSTEM::OTHER-ARGS)
For more information, evaluate (DISASSEMBLE #'BIT).
Documentation:
CLHS:
"Body/any_bit.html"
SYSTEM::FILE:
((DEFSETF #P"/Lisp/clisp/clisp-2.49/src/places.fas" 941 941))
Here, this may be of interest. Below is a short extract:
[Function] bit bit-array &rest subscripts sbit simple-bit-array &rest
subscripts
bit is exactly like aref but requires an array of bits, that is, one
of type (array bit). The result will always be 0 or 1. sbit is like
bit but additionally requires that the first argument be a simple
array (see section 2.5). Note that bit and sbit, unlike char and
schar, allow the first argument to be an array of any rank.
Bit Function clisp
Also, this is a huge index of links to appropriate section(s) of the clisp manual.
Related
New Common Lisper here. I have seen packages being declared with the pound colon syntax, as in (defpackage #:foo), but I have also seen them defined as plain keywords, as (defpackage :foo).
Which is considered "better"? What is the difference between these two? I read somewhere that pound colon simply means the keyword isn't interned. Is that true? If so, what are the advantages to defining a package with an uninterned keyword?
Package names are strings, but you can designate them using symbols, so you have basically the following options:
1. (defpackage foo ...)
2. (defpackage "FOO" ...)
3. (defpackage :foo ...)
4. (defpackage #:foo ...)
It is true that #:foo is an uninterned symbol, and the reason some people prefer to use that syntax is precisely because it does not "pollute" the current package (1) or the keyword package (3). Usually (1) is a big No because your defpackage form has a side-effect on whatever package is current, which is bad. At least (3) is more deterministic, you always pollute the keyword package.
Note that "polluting" is not so much a problem of having too many symbols in a package, but also the fact that it is harder to reverse the operation: delete-package cleans the package designated by the symbol, but there is still a symbol interned in another package that probably was not there before defpackage (and if it already was there, you don't want to unintern it).
Some people don't mind and use keyword symbols everywhere, and it is not "bad", it just has a potential for being a source of problems in some corner cases. It is usually better to use either a string (2) or an uninterned symbol (4).
The advantage of strings over symbols (interned or not) is that you control the case: it is possible to have different packages with names that are only distinct in case (e.g. "test" vs "TEST"), and while the standard defines how symbols are read by default (upcased), you don't know in advance if your package definition will be read by a Lisp environment that is setup in a standard way or a custom way (e.g. inverting the case before interning).
So ideally it should be more robust to use always literal strings: they do not intern a symbol and the case is explicit.
However, for some reason people tend to prefer writing #:foo: probably because it is not written in uppercase, or because there is no need for quotes, etc. I am not sure why honestly (strings are often a code smell in other circumstances so maybe we tend to avoid them).
Anyway, it has become a bit customary to use uninterned symbols. This is usually not a problem because (i) people tend to use the standard readtable and (ii) in case they customize it, it is quite stable during the execution of a Lisp environment: whether you upcase or downcase the symbol in the defpackage of some package P, the symbol will be read the same way in the (:use P) clause of another defpackage.
Package names are strings. But it is a good idea to specify them as symbols, because this buys you immunity to variants of CL which which do not have the same case behaviour as CL. As an example, Allegro CL has (or used to have: I have not looked at it for at least a decade) a mode where everything was lower-case by default. In that mode (symbol-name 'foo) would be "foo", and all the standard CL symbols were lower-case versions of themselves (so (symbol-name 'symbol-name) was "symbol-name".
If you wanted to write code which had any chance of running in an environment like that, you couldn't give packages names which were strings:
(defpackage "FOO"
...)
would mean that, in future, you'd need to type FOO:x and so on, which was horrible. Even worse, if you said
(defpackage "FOO"
...
(:export "X"))
You'd now have to type FOO:X. And something like this:
(defpackage "FOO"
(:use "CL")
(:export "X"))
would fail dismally because there was no package whose name was "CL" at all: its name, of course, was "cl".
So if you needed things to work with that environment you really wanted to type package names – and symbol names in packages – as symbols.
This also would mean that your code would have a chance of running in some future CL variant which really was lower-case, which many people assumed would probably happen at some point, since case-sensitive lower-case-preferred languages had clearly won by the late 1980s.
Given that there's a question of where you want the names to be interned. For symbols in a package it is generally very undesirable to intern them in the current package:
(defpackage foo
(:export x y z))
(use-package 'foo)
will fail.
So then there are two obvious choices:
intern things in the keyword package;
don't intern them.
It does not make much difference which you do in practice. Personally I intern package names in the keyword package as I want completion to work on them, but do not intern symbol names, because that seems just to be gratuitous clutter. So my package definitions look like
(defpackage :foo
(:use :cl ...)
(:export #:x #:y ...))
I want to build a macro that defines several classes and methods based on symbols that would have a root string (I guess this is not an unusual thing to do in lisp ^^).
dummy example :
(defmacro define-my-stuff (term)
would do such things as
defclass my-super-term-class
defvar *term-variable*
defun do-term ((a-thing *example-term*))
with symbols built upon the "term" macro parameter
How to deal with the different readtable-case so the code can be universally used with the four different type of cases (:UPCASE :DOWNCASE :PRESERVE :INVERT).
I want to be able to use these symbols from source code. So I want the symbols created inside the macro to be built by the reader readtable-case rule that is used by the lisp system.
(The regular is :UPCASE but some uses :DOWNCASE for example).
The only way I have found to do such a thing would be to use the READ-FROM-STRING function (example : (read-from-string (concatenate "term" "-variable"))
But this also interns the symbol as side effect.
So how should I compute a symbol following the readtable-case rule without interning it ?
Is there in function for that in the common-lisp package ?
You can use an uninterned symbol as a string designator:
(string '#:Foo)
=> "FOO"
or=> "foo"
or=> "Foo"
or=> "fOO"
You can create an uninterned symbol:
(read-from-string (concatenate 'string "#:" "term" "-variable")
But you need to be very careful with READ-FROM-STRING when trying to securely read from a not secure string. Common Lisp IIRC lacks a standard symbol parser which only does that operation in isolation - without read time evaluation and without reading arbitrary structures. There is probably in a library somewhere a 'secure' symbol parser, which the also checks the readtable case.
My lisp file contains about 50 function and macro definitions. At the head of the file is:
(defpackage :utils
(:use :common-lisp))
(in-package :utils)
; ... ~50 defuns/defmacros follow along with some other code
I want to export all these 50 definitions. But no other symbols.
To write them all out in :export clauses inside defpackage seems very tedious.
I tried getting the necessary symbols by using loop's facility for listing symbols in a package. But both "symbol" and "present-symbol" don't output the needed definition symbols. I could somehow subtract "external-symbols" and inherited symbols. But this seems like the kind of thing everyone would need and there should be an established easy solution. I looked around and haven't found a straightforward answer.
How do I export all the definition symbols without having to write them out individually and manually?
scan symbols
You can scan all symbols and export all that have a function binding (this includes macro names):
(defun export-fbound-symbols (package)
"export symbols with function bindings"
(do-symbols (s package)
(when (fboundp s)
(export s package))))
This is usually not a very good idea: good software engineering practice is to limit the set of public interfaces.
be more selective
You can redefine defun and defmacro so that they automatically export their definienda.
See exporting.lisp in CLISP. E.g.,
(defmacro define-function (name lambda-list &body body)
`(progn
(export ',name)
(defun ,name ,lambda-list ,#body)))
Note that this ignores the possibility of (defun (setf foo) (...) ...).
No, this is not something everyone needs. Usually, you'd export them as you write (and actually need) them.
I'd probably use an ad hoc keyboard macro for this. You could also write a little Lisp function to read your file form by form and output the relevant symbols for copy-paste.
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.
I love the idea of image-based languages, and lately I've been toying with Common Lisp via sbcl. I've read in a few places about how through being able to save and load back an image of the virtual machine, you can evolve an application or set of apps running on that image.
I get how to load code into an image and get it running, slime makes this sort of thing very nice, but my question is this: How can I tell what functions are defined in an image? Let's say I want to make an update to a function days or months after it has been running and I can't remember the name. Is there any way to get to the code or even just the names of the functions defined in an the image?
Now, I do write the code out into source and load it in via the repl, so I have a copy there, but it seems like this would be an obvious feature.
Common Lisp has the idea of packages. Packages are kind of a registry for symbols and are used as namespaces for symbols. You can ask Common Lisp for a list of all packages.
CL-USER 1 > (list-all-packages)
(#<The SQL-COMMON package, 0/4 internal, 28/32 external>
#<The LOOP package, 245/256 internal, 3/4 external>
#<The COMM package, 0/4 internal, 940/1024 external>
#<The REG package, 41/64 internal, 0/4 external>
...)
Each packages stores the interned symbols in some data structure. You can ask Common Lisp which symbols are interned in a package.
CL-USER 2 > (loop for symbol being
each external-symbol in (find-package "COMMON-LISP")
collect symbol)
(MAKE-ARRAY INVOKE-DEBUGGER STRING-TRIM ...)
To make that easier, Common Lisp provides functions APROPOS and APROPOS-LIST.
CL-USER 3 > (apropos "MAKE-LOCK")
MP::INTERNAL-MAKE-LOCK (defined)
MP:MAKE-LOCK (defined)
WWW-UTILS:MAKE-LOCK (defined)
MAKE-LOCK
RESOURCES::MAKE-LOCK (defined)
MINIPROC:MAKE-LOCK (defined)
Functions, Classes, etc. use symbols as their identifier. You can also ask a symbol, which function it denotes.
CL-USER 4 > (symbol-function 'www-utils:make-lock)
#<Function WWW-UTILS:MAKE-LOCK 41E006A69C>
Sometimes a Common Lisp also records the definition of functions. Then the function FUNCTION-LAMBDA-EXPRESSION can be used to retrieve 'it'.
CL-USER 5 > (defun foo (a) (* (sin a) a))
FOO
CL-USER 6 > (pprint (function-lambda-expression 'foo))
(LAMBDA (A)
(DECLARE (SYSTEM::SOURCE-LEVEL #<EQ Hash Table{0} 41403151C3>))
(DECLARE (LAMBDA-NAME FOO))
(* (SIN A) A))
But usually nowadays Common Lisp implementations don't use the recorded definitions, but record the locations of the source for each Lisp construct.
Most Common Lisp implementations can track the source locations in an implementation specific way.
The Common Lisp standard defines a function ED.
CL-USER 7 > (ed 'www-utils:make-lock)
This calls an editor (internal or external) and should open the source code for that function. To make that work, Common Lisp needs to keep track of the source location for each function. Next the editor needs to have access to that source. Sometimes the location recorded is an absolute path /Users/joswig/lisp/utils.lisp . If the editor wants to open that file, it should be accessible. But it is also possible to use logical pathnames like http:server;utils.lisp . This is then translated into a real physical pathname. This translation can later be configured. So it would be possible to move a Lisp to a different machine with different pathnames, configure the logical pathname HTTP and then the Lisp still finds all source code, even though it is on a different machine with a different file system structure. So, to make it work may need some configuration. But it is a very useful feature and it is widely used.
How the recording of source code and how the recording of source locations work is implementation dependent and is a feature of the respective Lisp in combination with its development environment. Better Lisp implementations have a lot of features in this area.
You can also use do-symbols or do-external-symbols if you prefer:
example:
>> (do-external-symbols (s (find-package :foo-package)) (print s))
FOO-PACKAGE:XXX
FOO-PACKAGE:YYY
FOO-PACKAGE:ZZZ
NIL
Where XXX, YYY & ZZZ are all external symbols in the package :foo-package.