Re: [spr8239] package-lock warning messages

[Eyvind Ness <eyvind.ness@hrp.no>]

  ;; Date: Wed, 28 April 1993, 14:19 -0700
  ;; From: Kevin Layer
  ;;
  ;; >> I'm also a bit annoyed by the persistence with which Allegro protects
  ;; >> the built-in CL symbols - I can't even locally override CL fundefs
  ;; >> within an FLET/LABELS without having a flood of warnings thrown at me.
  ;; 
  ;; This is discussed in the Allegro CL User Guide, page 3-25, volume 1.
  ;; In short, you can disable package locking, though it is strongly
  ;; discouraged.  You would not believe how many sprs we had because
  ;; people did this:
  ;; 
  ;; 	(defstruct instance ...)
  ;; 
  ;; which obviously clashes with make-instance if package locking is not
  ;; enabled.

Yes. Yes. Most of us know already, I think. What is so strange, in my
opinion, is that you can't *locally* override a cl-symbol within the
body of an FLET or LABELS without getting lots of annoying warning
messages. Note that I'm not making a permanent *change* to the
cl-definition - it's only a *temporary* redefinition of it. Also, I have
not found a proper way to bind EXCL:*ENABLE-PACKAGE-LOCKED-ERRORS* to
NIL while compiling and using a macro-definition that expands to a
function that uses FLET on a cl-symbol. What I have is something like:

(defmacro franz-dislikes-this-macro (&rest body)
 ...
 `(let ((excl:*enable-package-locked-errors* nil))
     ... 
     . ,body))


Which, needless to say, expands into a million warning messages at
compile time. In addition, the effect is that the redefiniton attempt
will be ignored.

I don't want to enter a discussion on the justification of such a macro.
I'm also aware of the fact that even if I bind the function definition
of a cl-symbol, the original function could be compiled inline into some
of the code within the body of the binding, risking that the new fundef
will remain unused throughout the body.

The following script should illustrate my point:

   USER(5): (defmacro bs (&rest body)
	      `(let ((excl:*enable-package-locked-errors* nil))
		 (flet ((break (&rest args)
			  (declare (ignore args))
			  "no brakes allowed"))
		   . ,body)))
   BS
   USER(6): (compile 'bs)
   BS
   NIL
   NIL
   USER(7): :ma (bs (some-bullshit))
   (LET ((*ENABLE-PACKAGE-LOCKED-ERRORS* NIL))
     (FLET ((BREAK (&REST ARGS) (DECLARE (IGNORE ARGS)) "no brakes allowed")) (SOME-BULLSHIT)))
   USER(8): (defun using-bs () (bs (funcall 'break "brakes?")))
   USING-BS
   USER(9): (compile 'using-bs)
   ; While compiling USING-BS:
   Warning: Compiling a FUNCTION definition for the name BREAK as a FLET.  This name is in the
	    #1=COMMON-LISP package and defining it will be a violation for portable programs.
	    The package #1# has PACKAGE-DEFINITION-LOCK set, which causes the system to check
	    for this violation.
   USING-BS
   T
   T
   USER(10): (using-bs)
   Break: brakes?

   Restart actions (select using :continue):
    0: return from break.
   [1c] USER(11): :pop
   USER(12): (uncompile 'using-bs)
   USING-BS
   USER(13): (LET ((*ENABLE-PACKAGE-LOCKED-ERRORS* NIL)) (compile 'using-bs))
   USING-BS
   NIL
   NIL
   USER(14): (using-bs)
   Break: brakes?

   Restart actions (select using :continue):
    0: return from break.
   [1c] USER(15): :pop
   USER(16): 

  ;; Also, there is a typo in the User Guide: the variable
  ;; excl:*enable-package-lock-errors* is really
  ;; excl:*enable-package-locked-errors*.

Fortunately, using the nice Emacs Lisp completion feature that is a
built-in of the Franz Elisp package and the ILISP package, many of these
errors can be avoided.

Eyvind.


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  Eyvind Ness         Internet: Eyvind.Ness@HRP.No
  Research Scientist  Voicenet: +47 69 183100 ext. 275
  CRS Division        Faxnet:   +47 69 187109
  OECD HRP            Papernet: PO Box 173, N-1751 Halden, Norway

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~