[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
'FOO:QUUX 'BAR:QUUX) => T ??
First (to say it politely) I don't see how your solution solves
anything. Second, the more obvious solution of making (EQL 'FOO:QUUX
'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the
presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.
I guess my idea wasn't well-worded. Let me try to clarify. I would
remove any association of symbols to packages, thus there would be no
FU:QUUX, there would just be QUUX. However, QUUX's value and function
would be attached to packages, thus we could speak of QUUX's function
in package FU, or QUUX's value in package BAR. Thus we have separate
name spaces for functions and values, without the ridiculosity of
having to do interning, or string coercion whenever comparison of
symbols is needed.
Hi. The notion you present is essentially the same as one I came up
with. Here is a summary of how I see it all working.
1. Symbols with the same name are identical. Symbols do not have
values, function-cells, package-cells, or property lists.
2. By definition, a BINDING associates a symbol and a "property"
(another symbol) with a value. A PACKAGE is a set of bindings.
At any given time, one package is current.
3. Defining constructs exist which create bindings and add them to the
current package. There are also referencing constructs which
access or mutate bindings. A binding may not be referenced before
it has been defined! (So bindings can not be created with SETF.)
(Names for defining constructs might be DEFVAR, DEFUN, DEFMACRO,
DEFTYPE, DEFSTRUCT, and so on, all of which would be special cases
of, say, DEFPROP.)
4. Constructs exist which allow a package to reference some of the
bindings of other packages. However, no two distinct bindings with
the same symbol and property may be referenceable (without
qualifiers) in any one package. Also, no package may redefine a
binding it did not define!
The above notion eliminates all spurious name clashes. It has several
drawbacks as far as Common Lisp is concerned. Here are the worst in
First, binding values are looked up (and possibly cached) as needed at
run time. I don't see how to do this efficiently. Second, Common Lisp
is already a standard, so major changes aren't reasonable. Finally,
while the above is the best I could come up with, I feel that there is
something else out there better. (For example, I don't know anything
Still, I think the idea you presented to be basically sound and
semantically a significant improvement over the status quo. Good
luck in getting Soley to see things the same way.