Re: Function CCL::STRUCTURE-SLOT-NAMES undefined.

[george@hsvaic.boeing.com (George Williams)]

On Oct 23, 12:07pm, Bill St. Clair wrote:
[...]
> >There should be some way that system packages can be write-protected,
> >so that if you try to INTERN anything into them that is not already
> >there an error is signalled. Is that mechanism available in any version
> >of MCL or is it proposed in future versions?
> 
> I have never heard this idea before. It sounds reasonable.
> Maybe it could be controlled by *warn-if-redefine-kernel* and signal
> a continuable error, just as DEFUN does when one attempts to redefine
> a kernel function. One drawback is that lots of the example files
> intern symbols in the CCL package. Opinions?

As David Moon points out, this feature exists on the LispMs, and doesn't
solve the problem originally posed.  I'm not that familiar with how it
works on the LispMs, but a similar capability exists in Franz's ACL and
work like this (reasonable disclaimers apply here):

 There is a system function (excl:package-lock in ACL) which accepts a
 package, and returns a boolean indication of whether that package is
 locked.  If it is locked, the system signals an error
 (package-locked-error in ACL) when code tries to do things like import
 a new symbol into the package (but not intern, curiously), export (or
 unexport or unintern or shadow) a symbol symbol from the package,
 change the name or the packages used by the package,

 The locked status of a package by using setf on the function & package.
 There is also a special variable (excl:*enable-package-locked-errors*
 in ACL) and a macro (excl:without-package-locks) which can be used to
 override the signaling, and the error is not signaled if the value of
 *package* is the package being modified.
 
 There is a parallel package definition locking which applies only to
 modifying function (and macro, type, structure, symbol macro, and
 compiler macro) definitions of symbols in the package, either globally
 (i.e., symbol-function, etc.) or lexically (flet, etc.).  There are
 similar functional, special, and macro mechanisms for overriding the
 locking.

>From my limited experience with it, this seems to be a reasonable and
useful approach to the issue.  I have bumped heads with it, but had the
tools to override it when it was necessary.

George Williams            BCS Huntsville Artificial Intelligence Center
Boeing Computer Services   Internet: george@hsvaic.boeing.com
POBox 240002, M/S JY-58    UUCP: ...!uw-beaver!bcsaic!hsvaic!george
Huntsville AL 35824-6402   Phone: 205+464-4968 FAX: 205+464-4930