Subject: Re: Packages
From: Erik Naggum <>
Date: Tue, 19 Mar 2002 06:42:36 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Joe Marshall
| I understand this.  What the package-system doesn't understand is that
| when I mentioned `foo' the first time (and got the unbound variable) was
| that I *didn't* want that symbol.  (Yeah, I know it cannot read my mind.)

  But if you typed it into the REPL, you must have been in the wrong
  package to begin with.  Why is that?  My guess is that you were in the
  common-lisp-user package and called use-package instead of changing the
  current package to a well-defined package that uses the packages you have
  defined.  I think you should be using in-package instead of use-package.

  In my opinion, you are using the package-system counter to its design
  when you randomly call use-package, regardless of whether it is because
  of this "error".  I tend to think it is just plain wrong to use the
  package operations interactively unless you are working to piece together
  a package in order to dump it to file prior to defining anything that
  depends on it having properly been set up.  In other words, you have a
  broken package definition to begin with when you need to call use-package
  to "fix" it.  And this is most likely the wrong "fix", too.

  You have probably thought that use-package is something very different
  than it is and are now frustrated that it is not what you think it is,
  but what you think and what it is are probably close enough not to give
  you a strong enough hint that you need to revise your concept of what it
  is.  May I suggest that you do a refresh read of the package concepts in
  the standard to see that your assumptions are actually valid?

  I tried to remember when I ran into problems like you describe, but it is
  quite hazy to me.  I must have changed the way I use Allegro CL compared
  to how I used CMUCL.  In particular, if I try to evaluate an unbound
  variable in ACL, I get these restarts:

(52) cl-user
Error: Attempt to take the value of the unbound variable `foo'.
  [condition type: unbound-variable]

Restart actions (select using :continue):
 0: Try evaluating foo again.
 1: Use :foo instead.
 2: Set the symbol-value of foo and use its value.
 3: Use a value without setting foo.
 4: Return to Top Level (an "abort" restart).
 5: Abort entirely from this process.

  CMUCL is quite deficient in the restart department:

* foo

Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable FOO is unbound.

  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

; File: target:code/eval.lisp

; File has been modified since compilation:
;   target:code/eval.lisp
; Using form offset instead of character position.

  I had to go through a manual apropos call to get the equivalent of
  restart 1 in ACL above.  That would be annoying, but this is a quality of
  implementation issue with CMUCL, not a design issue with packages.

  CMUCL does not by default print the package name, and there is no
  convenient way to change the package, so it seems to me that your having
  adopted this abuse of use-package may well be an history artifact and
  that you should now use in-package, instead.

* Kent Pitman
> It preserves the illusion that all symbols always exist
> by demand-creating any symbol upon mention.

| The illusion is imperfect.  When I (use-package ..)  I can tell if a
| symbol had been created on demand or not: I get errors for those that
| were.

  Really?  This would only be true of all symbol names were always distinct
  regardless of the package system.  Since this is obviously false and a
  use-package therefore can signal an error caused by two well-defined
  symbols in both packages, there is something wrong with your premises.

  I think your _premise_ is that the package system is broken and now you
  are only trying to find ways to "prove" it by doing things that would
  break _any_ working system.  I consider this prejudicial.

| No, I don't want a DWIM.  What I do want is something that is a bit more
| clever.  Consider this behavior: when I make a typo and get an unbound
| variable error, why not have the system unintern the symbol just created
| if and *only if* it was created by the typo itself.

  Would you want the reader to record the second value of intern for each
  symbol it has interned and make them available to the evaluator so it can
  safely unintern a symbol that causes a symbol and search all packages for
  a symbol with the same name and suggest them to you in case the user is
  unable to set up the package-system so it produces user-correct results?
  This sounds like a really bad solution to the wrong problem.

| These two behaviors (and note that I'd like that latter to be a user
| controlled switch so no one *has* to monitor the load process
| looking for these things) would greatly improve my relationship with the
| package system.

  The user-controlled switch exists and is called defpackage.  If you do
  not use an in-package form in your compiled source files, I think you
  deserve to lose, and if your package definitions are out of sync with
  respect to their actual interdepencies, even more so.

  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.