[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poor excuse for packages

> KMP hinted at a very interesting solution to the special-variables
> problem: let symbols in the package SPECIAL name special variables,
> and let all others name local variables.

But, but, then all specials are necessarily in the same package, and
we are back to the original problem that component subsystems cannot
ensure that their symbols will not clash with those of other

> It's cheap to detect, too, in interpreter or compiler: just check the
> package cell.  This I like.  Too bad it's too late.

This aspect is indeed nice!  I think to do it right, each package
would implicitly be split into two components: one subpackage
containing the specials, and one the non-specials.  (This use of
"subpackage" has nothing to do with the old LM notion of subpackage.)
The package name of the specials subpackage would be automatically
generated, perhaps by prepending `*'.  By reader convention, *:foo
would be the special variable foo in the current package.

The implementation would be such that the subpackages necessarily
share the same inheritance structure; naming either subpackage in
intern, import, export, shadow, etc., would be equivalent, except for
the implication of variable specialness.

On the balance, I agree this idea is not worth the pain.  However, its
consideration leads to an interesting question:  Can anyone think of a
situation in which it is useful or even reasonable to refer to a
non-special variable using an explicit package qualifier?