Subject: Re: Package System and new dialect From: Erik Naggum <email@example.com> Date: 1998/07/18 Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Kelly Murray | Basically, a want to have a new dialect of CL, which redefines (shadows) | some symbols in the lisp package. this certainly tells me that users of your package should _not_ :USE the COMMON-LISP package. | The problem is that now I want other packages to be able to just :use | this package, but this doesn't work because it creates conflicts with the | lisp package. only if they they also :USE "COMMON-LISP". but _why_ would they do that if they want your dialect? | I suppose I can have the other packages not :use the lisp package, | but then I must enumerate all the lisp symbols in the new-dialect | package, which I suppose is better, but still lots of work, | and because of implementation specific extensions, I could | never know all the symbols that must be exported. huh? there are 978 symbols in the COMMON-LISP package, all counted, none forgotten, and an implementation is _not_ allowed to export more symbols from the COMMON-LISP package. if your package does :USE COMMON-LISP, you can compute the :EXPORT list to re-export all of its symbols once and for all since you'll presumably override any pre-existing bindings via :SHADOW, anyway, and then perhaps remove symbols from the export list if you remove semantics. collecting the list of external symbols does not appear to be "lots of work" to me. the following should produce output that is reasonably pastable directly into a DEFPACKAGE form: (pprint (sort (loop for symbol being each external-symbol in "COMMON-LISP" collect (symbol-name symbol)) #'string<)) I don't understand the point about implementation-specific extensions. the symbols aren't even allowed to have bindings or associations apart from those specified in the standard, so you know _exactly_ what to do with all of these symbols, and it should even be eminently feasible to know in advance that some symbols should not be shadowed, such as EQL, which would screw up DEFMETHOD. | Basically, this solution just moves the problem back one more level, but | it still exists. really? the "problem" is now one of being explicit about using your dialect by specifying a :USE clause that does not include COMMON-LISP, but instead your dialect. that doesn't seem unfair, does it? #:Erik -- http://www.naggum.no/spam.html is about my spam protection scheme and how to guarantee that you reach me. in brief: if you reply to a news article of mine, be sure to include an In-Reply-To or References header with the message-ID of that message in it. otherwise, you need to read that page.