Re: Package problem, revisted

[<@IU.AI.SRI.COM:slug-admin@iu.ai.sri.com>]

>   From: Barry Margolin <barmar@Think.COM>
>   
>   Read the paragraph you're replying to.  He isn't
>   mentioning CLASS-PROTOTYPE at all.  It looks like a
>   package environment consistency problem. Specifically,
>   it seems like the ALP-CLOS package is being created
>   before the DEFPACKAGE is being loaded.

Oops, you're exactly right, Barmar.  Sorry folks.

>   Robin, does the file that contains the DEFPACKAGE for
>   ALP-CLOS also have a
>   "Package: ALP-CLOS" in the -*- line?  This line is
>   processed before compiling or executing the code
>   contained, so it could be creating the package
>   incorrectly.

This is one reason that you should always use strings instead of symbols within
a DEFPACKAGE form.  To illustrate the horrors of using symbols, consider the
following:

(defpackage foo                    ;bad style!
  (:use common-lisp)
  (:import-from clos class-precedence-list)
  (:export bar baz))

This form will create oodles of extraneous symbols in the current package when
read.  In fact, if this form is read into the FOO package, perhaps because of
the file attribute line, then trouble is sure to follow.  The reader will intern
a symbol having the name "CLASS-PRECEDENCE-LIST" into the current package when
this form is read.  Then when the :IMPORT-FROM clause is executed, *boom*, a
name conflict occurs.

Contrast the previous form with the following paragon of beauty:

(cl:defpackage "FOO"               ;much better!
  (:use "COMMON-LISP")
  (:import-from "CLOS" "CLASS-PRECEDENCE-LIST")
  (:export "BAR" "BAZ"))

This form will never create any symbols in the current package.  See pages
272-273 of CLtL/2 for a more detailed example.