Re: Packages

[Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.HP.COM>]

			.......
	
		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.
	
			-Sean Engelson-
	
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
my opinion.

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
about locales.)

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.

Greg Weeks