This is the org.tfeb.conduit-packages Reference Manual, version 5.0.0, generated automatically by Declt version 4.0 beta 2 "William Riker" on Tue Jul 15 04:49:19 2025 GMT+0.
The main system appears first, followed by any subsystem dependency.
org.tfeb.conduit-packagesConduit packages
Tim Bradshaw
MIT
5.0.0
pkg.lisp (file).
impl.lisp (file).
cometh.lisp (file).
Files are sorted by type and then listed depth-first from the systems components trees.
org.tfeb.conduit-packages/org.tfeb.conduit-packages.asdorg.tfeb.conduit-packages/pkg.lisporg.tfeb.conduit-packages/impl.lisporg.tfeb.conduit-packages/cometh.lisporg.tfeb.conduit-packages/org.tfeb.conduit-packages.asdorg.tfeb.conduit-packages (system).
org.tfeb.conduit-packages/pkg.lisporg.tfeb.conduit-packages (system).
org.tfeb.conduit-packages/impl.lisppkg.lisp (file).
org.tfeb.conduit-packages (system).
*define-package-mechanisms* (special variable).
*extended-cl-define-package-clause-keys* (special variable).
*underlying-package-implementations* (special variable).
compute-define-package-forms (generic function).
define-conduit-package (macro).
define-package (macro).
defpackage (macro).
delete-package (function).
export (function).
initial-define-package-state (generic function).
process-define-package-clause (generic function).
recompute-conduits (function).
rename-package (function).
unexport (function).
*conduit-package-descriptions* (special variable).
*conduit-packages* (special variable).
*package-conduits* (special variable).
canonicalise-package-name (function).
clean-package-alist (function).
compute-clone-clauses (function).
compute-conduit-clauses (function).
conduit-error (function).
conduit-error (condition).
ensure-external-symbol (function).
ensure-package (function).
funcall/ul (function).
make-package-conduit-package (function).
note-conduit (function).
note-conduits (function).
recompute-conduits-for (function).
underlying (function).
validate-conduits (function).
org.tfeb.conduit-packages/cometh.lispimpl.lisp (file).
org.tfeb.conduit-packages (system).
Packages are listed by definition order.
org.tfeb.conduit-packagescommon-lisp.
*define-package-mechanisms* (special variable).
*extended-cl-define-package-clause-keys* (special variable).
*underlying-package-implementations* (special variable).
compute-define-package-forms (generic function).
define-conduit-package (macro).
define-package (macro).
defpackage (macro).
delete-package (function).
export (function).
initial-define-package-state (generic function).
process-define-package-clause (generic function).
recompute-conduits (function).
rename-package (function).
unexport (function).
*conduit-package-descriptions* (special variable).
*conduit-packages* (special variable).
*package-conduits* (special variable).
canonicalise-package-name (function).
clean-package-alist (function).
compute-clone-clauses (function).
compute-conduit-clauses (function).
conduit-error (function).
conduit-error (condition).
ensure-external-symbol (function).
ensure-package (function).
funcall/ul (function).
make-package-conduit-package (function).
note-conduit (function).
note-conduits (function).
recompute-conduits-for (function).
underlying (function).
validate-conduits (function).
Definitions are sorted by export status, category, package, and then by lexicographic order.
A list of mechanism names for conduit packages’ DEFINE-PACKAGE
For each of these mechanism names, EQL methods must be defined on
INITIAL-DEFINE-PACKAGE-STATE, PROCESS-DEFINE-PACKAGE-CLAUSE and
COMPUTE-DEFINE-PACKAGE-FORMS, which see.
You can (and should) add and remove your own entries to this variable, but don’t muck around with other people’s.
A list of DEFPACKAGE clause keywords which should be treated as part of CL
Clauses with these keywords will be handled by the CL clause handler
An alist which maps from names which conduits provides new
implementations for and their underlying implementation function
names. You can use this if you want to layer conduits on top of some
other system which already is providing its own versions of these
names. By default the underlying names are just the standard CL
functions.
The keys of this alist are keywords, corresponding to the name in the CL package, to avoid any package confusion.
Version of DEFINE-PACKAGE which adds a (:use)
This also checks for explicit (:use x) clauses and signals appropriate
restartable errors.
See DEFINE-PACKAGE
Extensible variant of DEFPACKAGE
This macro is like CL:DEFPACKAGE, and supports the standard
CL clauses, some optional common extended clauses (see
*EXTENDED-CL-DEFINE-PACKAGE-CLAUSE-KEYS*, as well as conduit packages and
package cloning. See *DEFINE-PACKAGE-MECHANISMS* and the the
documentation of conduit packages for the extension mechanism for this
macro.
DEFPACKAGE for conduit packages
This version of DEFPACKAGE is like CL’s DEFPACKAGE, but can define a
‘conduit package’: that you can use as a conduit to extend existing
packages. This works by importing symbols from the existing packages
and then reexporting them. The syntax is as DEFPACKAGE, with the
addition of three new clauses:
(:EXTENDS package) takes package and reexports all its symbols;
(:EXTENDS/INCLUDING package . syms/names) reexports only syms/names;
(:EXTENDS/EXCLUDING package . syms/names) reexports all *but* syms/names.
When defining a conduit package you almost certainly will want to say (:USE)
to prevent the CL package being used.
This version of DEFPACKAGE also support ‘cloning’ packages: making another
package which is ‘just like’ an existing package. This means that all the
internal, exported and shadowing symbols in the clone will be the same as
those in the cloned package, but any additional things defined by DEFPACKAGE
will also take effect. This allows you to essentially make a copy of
a package which you can then use to define new functionality without
interning a lot of things in the original package. Cloning is a static
operation - packages do not know who their clones are, and no attempt is made
to keep clones up to date. Cloning is done by the clause
(:CLONES package)
Cloning is not compatible with extending (this is checked).
As with extending you probably want to specify (:USE) when cloning.
This version of DEFPACKAGE is simply a shim around DEFINE-PACKAGE, which see
Clean up the lists of conduits, and recompute all conduit packages to make them consistent
Compute forms for the expansion of DEFINE-PACKAGE for a mechanism
This is called for each mechanism in *DEFINE-PACKAGE-MECHANISMS* and each
clause in the DEFINE-PACKAGE form. Generally you should define EQL methods
on this generic function for any mechanism you want to add.
Arguments are:
- the mechanism name, a symbol;
- the final state for this mechanism;
- the name of the package being defined;
- all the DEFINE-PACKAGE clauses.
This must return three values:
- a list of forms which will be evaluated before the final DEFPACKAGE form;
- a list of clauses to add to the DEFPACKAGE form;
- a list of forms which will be evaluated after the DEFPACKAGE form.
Both the before forms and after forms will be evaluated within an ‘(eval-when (:compile-toplevel :load-toplevel :execute) ...) form.
Return the initial state for a DEFINE-PACKAGE mechanism
This is called for each mechanism in *define-package-mechanisms*.
Generally you should define EQL methods on this generic function for
any mechanism name you want to add.
Arguments are the mechanism name, the name of the package being
defined and all the clauses for the DEFINE-PACKAGE form.
The state this returns can be any object at all, and is handed to both calls to PROCESS-DEFINE-PACKAGE-CLAUSE and COMPUTE-DEFINE-PACKAGE-FORMS. It may be mutated freely by the appropriate methods for these generic functions.
Process a define-package clause for a mechanism
This is called for each mechanism in *DEFINE-PACKAGE-MECHANISMS* and each
clause in the DEFINE-PACKAGE form. Generally you should define EQL methods
on this generic function for any mechanism you want to add.
Arguments are
- the mechanism, a symbol;
- the keyword of the DEFINE-PACKAGE clause, a keyword;
- the whole DEFINE-PACKAGE clause being processed, a list;
- the current state for the mechanism;
- the name of the package being defined;
- all the DEFINE-PACKAGE clauses.
This should return two values:
- an updated state for this mechanism;
- a boolean indicating whether it handled the key
Note that each mechanism gets given each clause, so more than one mechanism can handle a clause. But unless at least one mechanism does an error will be signalled.
package-error.
simple-error.
| Jump to: | C D E F G I M N P R U V |
|---|
| Jump to: | C D E F G I M N P R U V |
|---|
| Jump to: | *
S |
|---|
| Jump to: | *
S |
|---|
| Jump to: | C F I O P S |
|---|
| Jump to: | C F I O P S |
|---|