[Openmcl-devel] with-package

[Robert Goldman]

On 1/12/13 Jan 12 -9:30 AM, Taoufik Dachraoui wrote:
> I am wrote a very simple package system that I am using for all my
> developments, I wanted to add
> the macro with-package so that I can use a package temporarily and then
> revert to previous context
> just before using the package.

I won't presume to dictate your personal programming style.  However, I
feel free to *suggest* that this may not work out well.

The package is effectively a big, invisible global variable, and having
the correctness of your code depend on it can make its behavior
unpredictable and difficult to understand.

This is related to the discussion of DEFPACKAGE in the spec:

"It is recommended that the entire package definition is put in a single
place, and that all the package definitions of a program are in a single
file. This file can be loaded before loading or compiling anything else
that depends on those packages. Such a file can be read in the
COMMON-LISP-USER package, avoiding any initial state issues."

Reading between the lines, I suggest that this recommendation is
intended to provide a transparent, easy-to-understand interpretation of
the packages, so that the set of accessible names, and their
interpretations is easy for the reader of code to predict.  Pushing and
popping available symbols tends to work against this.  It also, as has
been pointed out, can involve the need to understand issues of
compile-time, load-time, and execute-time evaluation.

I offer an additional heuristic: if something you are doing requires
attention to the subtleties of evaluation time, consider a different
method.  This is only a heuristic, because there are important tasks
that can be done well by exploiting, e.g., compile-time execution
subtleties.  Nevertheless, it's useful to consider alternatives when coding.

The principle is the same as when writing expository prose: avoid
complex constructions when they are unnecessary, since making the reader
spend a lot of effort to understand incurs a risk of misunderstanding.

Again, it's your code; do what you like with it, but simpler
constructions may serve you better in the long run.

Cheers,
r