Method and Generic Function internal names

[smh@franz.com (Steven M. Haflich)]

   From: franz!postgres.Berkeley.EDU!konstan (Joe Konstan)
   It seems that pcl generates names for methods and setf generic
   functions by creating a symbol which includes a fully qualified
   name for the slot or method name.  As a result, I have had
   occasions where a reference to a method was made at a time when
   that name was not yet exported, but the method defninition occurred
   using the exported name.

   Has this changed in later PCL versions?

   Is it likely that PCL will eventually name methods and generic
   functions with names which are transparent across import/export?

I don't have the 12/88 PCL handy to check, but the current (Victoria
Day) PCL seems to be exposed to the same problem.  Here's the relevant
code from pcl/defs.lisp:

(defun get-setf-function-name (name)
  (or (gethash name *setf-function-names*)
      (setf (gethash name *setf-function-names*)
	    (intern (let ((*package* *the-pcl-package*)
			  (*print-case* :upcase)
			  (*print-gensym* 't))
		      (format nil "~A ~S" 'setf name))
		    *the-pcl-package*))))

Perhaps the INTERN could have been written this way, which is intended
to be equivalent except that it always prints package qualifiers with
two colons.  (It's untested.)

	    (intern (let* ((pack (symbol-package name))
			   (*package* (or pack *the-pcl-package*))
			   (*print-case* :upcase)
			   (*print-gensym* 't))
		      (format nil "~A ~:[~*~;~A::~]~S"
			      'setf
			      pack
			      (and pack (package-name pack))
			      name))
		    *the-pcl-package*)

This removes the dependency on externalness of the symbol.  (But it
depends on the package name not requiring escape chars, and you'll
also lose if you change the home package of NAME, but get real...)

The location and details of this code may have changed since 12/88,
but you may be able to make analogous changes.  You might have to
recompile all of pcl after making the change...

How names like this should be generated is something of a religious
issue.  We will be using function specs in Franz's version of CLOS to
avoid problems like this, but there is of course something to be said
for or against each style.