Code is here:

http://www.flownet.com/ron/lisp/lexicons.lisp

Documentation is here:

http://www.flownet.com/ron/lisp/lexicons.pdf

Lexicons are first-class lexical environments for Common Lisp, what in
other languages would be called modules or namespaces.  They are
designed to be an adjunct, or potentially a replacement (depending on
your needs) for packages.  Packages map strings on to symbols at
read-time.  Lexicons map symbols onto bindings at compile-time.  For
writing modular code, lexicons can be significantly more convenient than
packages.  In particular, lexicons are unaffected by read-time
side-effects, and there is no need to manually maintain lists of
exported symbols.

This version has been tested only on Clozure Common Lisp, but it is
written in portable ANSI Common Lisp so it should run under any
conforming implementation.

Comments and feedback are welcome.

  This approach allows minimize both import and use-package operations
and it is relatively safe. It does not remove the need to export some
symbols manually when you want, say, have a custom + or - in your
package. Idea is borrowed from sql syntax:

select t1.id, t2.id, t1.unique_field_of_t1 from t1, t2 where
t1.id=t2.t1_id

  Which proved in my practice to be fairly reliable and convinient.
  I say it just in case you didn't read the topic with keywords
"symbol clashes - how to avoid them"

IMHO, the central problem with packages is that they try to resolve
namespaces at read time, when this ought to be done at compile-time.  
The appropriate information for resolving namespaces is simply not
available at read-time.  So the problems with packages cannot be solved
by changing the reader.

Note that this issue is in some sense the converse of the one
investigated by Kent Pitman a long time ago:

http://www.nhplace.com/kent/PS/Ambitious.html

The ultimate goal is to be able to take existing code, remove (nearly)
all the package-related stuff, move everything into the (not yet
implemented) LEXICONS package, and have it all Just Work.  This may be a
pipe dream, but the fact that there is now a very close correspondence
between lexicons and packages makes me optimistic.

Only there is nothing hard about the package system unless your cup is
full and you want it to be like some other thing but everything is like
that.

Out of curiosity, what kind of "symbol sorting" are you using packages
for?

You have symbols with the same symbol-name. You want them to be
different objects still, and you don't want the emacs lisp "solution"
(um, make them have different names...). I mean, not much more to it.

Personally, I've used it for an (unreleased and half-assed) glsl and c
translators usable in one image, in combination, that used e.g.
glsl:main and c:main.  Probably more stuff.

It modifies some global object (i.e. the list of lexicons).

This is not consistent with the usual semantics of MAKE-* functions
and should probably be called DEFLEXICON instead.

In an ideal world, MAKE-LEXICON would not modify a global.  It would
also allow you to make anonymous lexicons, and multiple lexicons with
the same name.  But it is not possible to make anonymous packages, nor
is it possible to make multiple packages with the same name, since both
of these would undermine the whole point of having packages.  (Note that
these features would not necessarily undermine the utility of lexicons,
which is IMHO another indication that lexicons are the Right Way to
achieve modularity.)

I did it this way because I thought that it would make package fans feel
warmer and fuzzier about lexicons to know that the binding of a symbol S
in lexicon L was invariably the symbol L::S.  It would be easy enough to
abandon this invariant and just use uninterned symbols for the bindings
instead.  But personally, although I am no fan of packages, the current
design has kind of grown on me.  It's far from clear that enforcing the
global uniqueness of lexicon names is a bad idea, even if it may not be
logically necessary.

But if you cannot explaint it with simple words, you may also use
complicated words, we've got good dictionaries.

Let's start without packages, and try to solve some simple practical
problems.

Assume we create two symbols with the same name, "ABC", and "bind" them
to different values:

[11]> (list (list (make-symbol "ABC") 1) (list (make-symbol "ABC") 2))
((#:ABC 1) (#:ABC 2))

Then we can find a symbol from a name, for example when we read the
string "ABC" from the user, we wan to find what symbol it corresponds
to, and retrieve its value:

[12]> (let ((syms (list (list (make-symbol "ABC") 1) (list (make-symbol "ABC") 2))))
        (second (find "ABC" syms :key (function first) :test (function string=))))
1

But how could we find instead the other symbol named "ABC", with value
2?  The solution proposed is to put the symbols in different
lists, named "packages", having different names.  So now, we can find a
symbol named "ABC" in a current 'package' refered to by *pack*, or a
symbol named "ABC" qualified by a package name such as "YOUR::ABC".

[14]> (let ((packs (list (list "MINE" (list (make-symbol "ABC") 1))
                         (list "YOUR" (list (make-symbol "ABC") 2))))
            (*pack* "MINE"))
  (list (second (find "ABC" (rest (find *pack* packs
                                        :key (function first) :test (function string=)))
                      :key (function first) :test (function string=)))
        (second (find "ABC" (rest (find "YOUR" packs
                                        :key (function first) :test (function string=)))
                      :key (function first) :test (function string=)))))
(1 2)

CL:IMPORT puts a symbol on the list of symbols of a package.
CL:FIND-SYMBOL finds a symbol in the list of symbols of a package.
CL:FIND-PACKAGE finds a package in the list of packages.

CL:INTERN does both CL:FIND-SYMBOL, and if not found, CL:MAKE-SYMBOL and CL:IMPORT.

With CL:USE-PACKAGE, there's a little technicality,  in that the symbols
from the used packages are not really "interned" or "imported" into the
using package, but it works most of the time exactly the same.

Each package maintains also a list of "exported" symbols, and this is
used only to signal an error when you try to read a qualified symbol
that is not exported with only one colon.

              SYMB is exported from PACK    SYMB is not exported from PACK
PACK:SYMB              ok                             error
PACK::SYMB             ok                               ok

http://smuglispweeny.blogspot.com/2008/12/why-lisp-packages-are-so-ea...

The biggest practical problem with packages, and the central motivation
for lexicons, is that exported symbol lists have to be maintained
manually.  This violates the DRY principle, and makes maintenance more
difficult than it needs to be, rather like the burden imposed by C on
the programmer to maintain the .c file and the .h files in parallel.  
Lexicons let you write modular code without manually maintaining an
export list.

A secondary problem with packages is that because they do what they do
at read time, merely parsing the program has potential side-effects
(interning symbols).  If you attempt to parse a program in an
environment where your packages have not been set up properly, these
side effects can end up messing up your environment to the point where
recovery is very difficult because you suddenly have a zillion symbol
interned in a package where they should not be interned.  Lexicons avoid
this problem because they operate at compile time, not read time.  They
also have a deferred binding mechanism that allows recovery from
unresolved bindings cause by missing libraries to be done at run-time,
so if you don't have your libraries set up properly you can recover by
simply importing the right library.  You don't have to recompile the
client code.

The vast majority of symbols that beginning and work-a-day Lispers deal
with are interned by the reader, and most non-advanced Lisp programmers
think about modular programming in terms of exporting functions,
classes, macros, and methods, not symbols.  If you doubt this, do a
Google search in c.l.l. for "How do I export a function?" and see how
many hits you get.

http://www.flownet.com/ron/packages.pdf

IMHO, packages, i.e. managing the mapping from strings to symbols, solve
the problem better than modules, i.e. managing the mapping from
identifiers to concepts. So I wouldn't agree that they do the wrong
thing, to the contrary, I think they do the right thing. But it's good
that you put a smiley there... ;)

Pascal

With a CL-style package system, the choice is always unambiguous: If you
use the same symbol as somebody else, you definitely mean the same
concept. If you want to denote a different concept, you have to use a
different symbol. It's much harder to make such distinctions with module
systems.

[Maybe having both packages and modules, like your lexicons, in the same
system is beneficial in that it provides the functionalities of both
worlds - but I cannot tell because I haven't tried this.]

Pascal

CL-USER> (defpackage :a)
#<PACKAGE "A">
CL-USER> (defpackage :b)
#<PACKAGE "B">
CL-USER> (make-lexicon :=l=)
#<Lexicon =L=>
CL-USER> (in-lexicon :=l=)
#<Lexicon =L=>
CL-USER> (ldefun a::x () "one")
=L=::X
CL-USER> (ldefun b::x () "two")
STYLE-WARNING: redefining =L=::X in DEFUN
=L=::X
CL-USER> (a::x)
"two"