[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: ram@CMU-CS-C.ARPA
- Subject: "home-ifying" symbols
- From: Jon White <JLW@SU-AI.ARPA>
- Date: Thu, 04 Apr 1985 17:45:00 -0000
- Cc: gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
Several people, yourself included, have suggested that if a luser
sets a symbol's package cell to something random then "the system
will get very confused".
The package cell seems to affect *nothing* in the system except
print, and there is nothing particularly confusing about the
fact that print will want to
1) certify either a nil or a package in that cell, and
2) output a #: prefix if it was nil.
Given the current capabilities of unintern, there seems to be no way
to avoid the so-called pathalogical situation wherein a symbol is
"homed" nowhere, yet accessible from one or more packages [shall we
call such a non-homed symbol a "bastard" since no one "owns" it?]
The problem with trying to insure the existence of a home through
side-effects in INTERN and/or IMPORT is that that doesn't address the
issue that's been galling us all along. Namely, a symbol is present
in several packages, and owned by one of them; but the luser decides
that it is homed * in the wrong package * and he wishes to change it.
How about having a set-symbol-package capablity which certifies
that the symbol is at least present in the package that it is
being "homed" in? Would that satisfy your feeling for constraints?
-- JonL --
P.S. Two uses of "certify" above mean "run a cerror if condition not met".