Is It Better Practice To Use package-name:symbol In Code Or :use :package-name In A DEFPACKAGE?

Question

This is I suspect, a matter of style and/or personal taste but I thought I'd ask anyway.

I have been in the habit of defining packages thus:

(defpackage :wibble
  (:use :cl :drakma)
  (:export :main))

Once I have executed IN-PACKAGE (:wibble, in this case), I can then use the symbols in DRAKMA unadorned:

(http-request ...

Then I recently read that seasoned Lisp hackers would rather not :use but:

(drakma:http-request ...

Just wondered what the consensus of opinion was on here and whether there were any pros or cons (not that type of CONS :) ) either way?

Cheers,

Peter

Answer 1

When you use a package, there are a couple subtle ways things might go wrong if the used package changes.

First, the package might export more symbols in the future. If, for example, the package exports a new symbol library:rhombus and you're already using that myapp::rhombus to name something, you are suddenly using the inherited symbol, with all possible attachments (e.g. classes, defuns, macros, etc), with sometimes strange results. If you use qualified symbol names, you will not get any more or any less than the symbols you want.

Second, the package might stop exporting symbols in the future. So if, for example, library:with-rhombus disappears, your call to (with-rhombus (42 42 42) ...) will suddenly get an error for an invalid function call (42 ...) rather than something that points directly to the source of the problem, the "missing" symbol. If you use qualified symbol names, you will get an error along the lines of Symbol WITH-RHOMBUS is not exported from the LIBRARY package which is clearer.

Importing symbols (with :import-from or :shadowing-import-from or import) is not without its own trouble. Importing works on any symbol, regardless of whether it's external or not. So it could be the case that the symbol is now library::rhombus, i.e. not intended for public consumption any more, but importing will still work with no errors.

Which option you use depends on your comfort level with the source package. Do you control it, and you will not make any conflicting changes without thorough testing? Go ahead and import or use to your heart's content. Otherwise, be careful about checking for unintended side-effects as library package interfaces change.

Answer 2

This is more a style issue, so it's impossible to categorize it in black and white, but here are the pros and cons:

1. Using package-qualified symbols.

   Avoids symbol conflicts.

   Allows to clearly distinguish foreign symbols.

   Allows to easily search, replace, copy,... uses of a certain symbol from the external library (for refactoring, extracting the code to some other place etc.)

   Makes code uglier, but only when library names are too long. (For example, I add a nickname re to cl-pprce, and now the code using it is even better, than w/o qualification: think re:scan)

2. Importing the whole package

   Basically, the opposite of the previous case. But I tend to use it with utility libraries, because using qualified names often beats their whole purpose of making code more concise and clear :)

3. :import-from package symbol

   This is one option you've forgotten to mention. I think it may be useful, when you use one or too very distinct symbols from a certain package very frequently. It also allows to import unexported symbols.