Local Package Aliases
Allows to define inside of a package aliases to refer other packages.
Provides a reader macro
$ to use the aliases (active only in packages having
alias mapping, and does not affect other code).
(defun func () "hello")
(defpackage some-application (:use cl))
(local-package-aliases:set #:com.my-company.some-library #:lib
;; => COM.MY-COMPANY.SOME-LIBRARY:FUNC
;; => "hello"
;; The aliases are not global, they are scoped only to the package
;; where they are defined:
;; => ERROR There is no package named "$LIB" .
;; The $ reader macro is non-terminating,
;; therefore it is only activated when $
;; is on the beginning of a token.
;; $ in the middle of a token has no special
;; => JUST-A-$-SYMBOL
;; The $ designates alias reference only if the
;; current package has alias mapping defined. If there
;; is no alias mapping in the current package, then
;; $ is interpreted as usually:
(local-package-aliases:set) ;; installs empty aliases mapping
;; => $-A-SYMBOL
;; => $-A-SYMBOL
;; Therefore it is safe to enable $ macro
;; globally, for example from Lisp init file,
;; without affecting the code using $ for other
To enable the
$ macro in your lisp session (may be put into
the lisp initialization file):
Another macro character than
$ may be used.
See the docstring for
for parameters description.
To return to the standard syntax:
(set-syntax-from-char #\$ #\$ readtable (copy-readtable nil))
To make the
$ macro enabled when your ASDF system
is compiled by other people, use the
:components ((:file "some-application")))
SLIME assumes standard readtable when meets tokens like
and doesn't undersdand our aliases.
In result SLIME symbol completion, slime-edit-definition, function
arguments hints do not work out of box for aliased tokens like
The solution we found is to hook into swank, and wrap evaluation
of every SLIME request with temporary adding the aliases defined
in the current package as nicknames for their corresponding packages.
So, during dynamic extent of every slime request, the aliases become
real package nicknames and SLIME can handle them as usually.
It must be noted that this solution is not entierly transarent:
when working from SLIME not only reader understands the aliases,
(find-package :$lib) will find the package.
But of course during normal run-time only reader knows about
this SLIME support.
To have the SIME support enabled automatically add the following
to your ~/.swank.lisp:
(when (find-package :local-package-aliases)
(funcall (read-from-string "local-package-aliases:hook-into-swank")))
Or this in ~/.emacs:
(slime-eval '(cl:when (cl:find-package :local-package-aliases)
(cl:funcall (cl:read-from-string "local-package-aliases:hook-into-swank"))))))
Other Package Aliasing Approaches
Here is some information, solutions and ideas I encountered recently
related to package aliases.
The solutions vary in:
- whether the aliases only honored by reader, or they also
affect functions like
- is the solution a portable Common Lisp or it relies on patches
or language extensions
whether the aliases are scoped to a package, or somehow else
whether the solution is specific about aliasing scheme,
or it's a lower-level tool allowing to build various
cl-package-aliases - http://www.cliki.net/cl-package-aliases
Provides patches for 5 lisp implementations to introduce
aliases. Aliases are scoped to package and visible both
for reader and for standard functions like
package-renaming - http://common-lisp.net/gitweb?p=users/frideau/package-renaming.git;a=tree
Tools based on
cl:rename-package to temporary give packages
desired short names/nicknames. Portable. To make the renaming
local it is expected to be used with the ASDF's
CL language extensions
There were discussions to develop a CL language extension
and propose it to CL vendors. The extension might be
a hook called by CL to resolve package prefix. I.e. when
CL encounteres a token like
pkg:symbol it calls the hook
with "pkg" string and the hook should return a package object
or maybe just a string designating real package name.
Such hook may be called
Alternatively the hook may be passed the full token "pkg:symbol"
and be responsible to resolve both package name and symbol.
Such hook may be named
There were considerations whether these hooks should be called only
form reader or by
cl:find-sybmol and other functions.
Sketch for a CDR: http://paste.lisp.org/display/133561
Discussions on the #lisp irc channel:
One more possible language extension would be to allow to
fully substitute the lisp reader. In this case there might
be are public library implementing fully compliant CL reader.
Lisp implementation will delegate functions like
and others to the pluggable reader. The reader by default
cl:*package* and other variables,
but also allows any custom hooks we need, such as described
It must be noted that interface between CL and such a pluggable
reader will consist of many functions. Also, the reader should
come with it's own implementations for all the reader macros,
because standard reader macros are not implemented in terms
cl:* functions, but use private, not-exported
functions of the CL reader, such as
If speak about pluggable reader, it's necessary to mention
the reader-interception project:
It's a portable solution allowing to plug-in your own reader.
It relies on the trick to look at the first character of input,
configure this character temporary as a reader macro, and
then this reader macro may read the full input stream according
to any rules.
The local-package-aliases approach with reader macro seems
to be a decent approach, especially as the syntax change
only affects packages with explicitly configured aliasing
It is comparable by convenience with package-renaming.
Advantage of local-package-aliases is that it may be enabled
once and forewer in the Lisp initialization file, while
packag-renaming will require you to manually rename packages
every time you switch projects or subsystems during or at the beginning
of Lisp session.
In my opinion a form of package aliasing deserves to be
introduced as a CL extension into all implementations.
The language extension may be specific, targeting only package
aliases (like cl-package-aliases project proposes).
It will encourage consistent coding practice accross
all the CL programs.
To simplify adoption of the extension by the CL implementations,
I believe it would be enought to have aliasing only in reader.
cl:find-package are rare, we can pass
full package names to it. On the other hand, if
is unaware of aliases, it may complicate support by SLIME.
As for more low-level language extenstions, like pluggable
reader or various hooks, I would welcome them too,
just to make Lisp more programmable and allow programmers
to solve their needs simpler.
Anton Vodonosov, firstname.lastname@example.org