Subject: Re: Packages From: Erik Naggum <erik@naggum.net> Date: Tue, 19 Mar 2002 06:42:36 GMT Newsgroups: comp.lang.lisp Message-ID: <3225508968313497@naggum.net> * 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 foo 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. Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (EVAL FOO) Source: ; File: target:code/eval.lisp ; File has been modified since compilation: ; target:code/eval.lisp ; Using form offset instead of character position. (SYMBOL-VALUE EXP) 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.