A Wafer Thin Common LISP Package Primer
Common LISP packages tend to trip up noobs presumably only familiar with packages as found in other languages; in those languages you usually have a file that contains a package and that package is only defined in that one file. We might call this a file-package. This is obviously a simplification; usually other languages have various ways to break the file-package rule, e.g. code to import things into or from somewhere else, dynamic loading, monkey patching, LD_PRELOAD, and worse.
Common LISP is, for some reason, rather REPL oriented--while you can create systems with Another System Definition Facility (ASDF) that contain something like the file-package as found in other languages, you can also type up a new package in the REPL, "change directory" into it, and wrangle various symbols therein. Packages thus can be built up or changed incrementally:
$ sbcl --noinform
* (defpackage :foo (:use :cl))
#
* (in-package :foo)
#
* (defparameter *foo* 42)
*FOO*
* (defun foo () *foo*)
FOO
* (in-package :common-lisp-user)
#
* (foo::foo)
42
* (defpackage :bar)
#
* (in-package :bar)
#
* (cl:defparameter *bar* 640)
*BAR*
* (cl:defun bar () (cl:values (foo::foo) *bar*))
BAR
* (bar)
42
640
* (in-package :cl-user)
#
* *package*
#
* (quit)
Now, there are good reasons to go with a file-package setup: files can be lobbed into version control, and files may integrate better with Integrated Development Environments than text scrolling to infinity in a REPL buffer. (I'm somewhat guessing here about IDE; the last IDE I used was Xcode, and that was a long time ago. Apparently there is M-. in emacs to find where code lives? But I am a barbarian unix sysadmin who uses vi to edit things.) But if you just want to mess around without the file-package formalism, LISP won't get in your way.
Details vary, but the HyperSpec usually can be found in an operating system port or package for offline use, e.g. `doas pkg_add clisp-hyperspec` on OpenBSD.
tags #lisp