Subject: Re: Package System and new dialect
From: Erik Naggum <clerik@naggum.no>
Date: 1998/07/18
Newsgroups: comp.lang.lisp
Message-ID: <3109738478791358@naggum.no>

* 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.