Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!usc!apple!agate!shelby!neon!lucid.com!jwz
From: jwz@lucid.com (Jamie Zawinski)
Newsgroups: comp.lang.clos
Subject: Re: clos and packages
Message-ID: <JWZ.90Dec10204557@kolyma.lucid.com>
Date: 11 Dec 90 04:45:57 GMT
References: <183@anaxagoras.ils.nwu.edu>
Sender: jwz@lucid.com
Organization: Lucid, Inc., Menlo Park, CA
Lines: 39
In-reply-to: brand@ils.nwu.edu's message of 10 Dec 90 23:50:28 GMT

In article <183@anaxagoras.ils.nwu.edu> brand@ils.nwu.edu (Matthew Brand) wrote:
> 
> 	Evidently in Common Lisp, CLOS and packages don't get along
> 	very well.  Specifically, it's impossible to export a method
> 	from two packages and then use them without producing a name 
> 	clash.  

You can accomplish this by setting up the package state the way you want it
beforehand; something like (using your example):

	(make-package "SPLINE")
	(make-package "FRACTAL")
	(export 'spline::show "SPLINE")
	(import 'spline:show "FRACTAL")

;; ... then you load your programs, effectively doing

	(in-package "SPLINE")
	(export 'show)  		; this is the symbol SPLINE:SHOW
	(in-package "FRACTAL")
	(export 'show)			; this also is SPLINE:SHOW

	(in-package "MYPACK" :use '("LISP" "SPLINE" "FRACTAL"))
	'show				; no conflict.

Given the way the package system interacts with the reader, it's not unusual
to have to tailor the package state before loading anything; in fact, doing so
can save you lots of pain and agony even if it's not strictly necessary.

> Whoever wrote the intern function forgot to check whether or not a symbol
> references a method; in that case interning should proceed, provided that 
> the argument lists are congruent.

The behaviour of INTERN has nothing to do with whether a symbol has a function
or method definition; it operates only on symbols and package hierarchies.
Lisp's namespaces are tied to symbols inseperably, so it's not possible to
import a variable FOO without also importing some hypothetical function FOO 
as well.
		-- Jamie