My earlier DEFSTRUCT bug report

[Eugene C. Ciccarelli <ECC at MIT-AI>]

In Zwei in LMFILE-Remote 17.1, MIT-Specific 9.0, System 86.30,
ZMail 45.1, Experimental Remote-File 11.0, Experimental Local-File 38.0,
microcode 124, Saver LFS, on Lisp Machine Four:

Ok, I've finally been able to isolate something that fails and yet doesn't
require my large environment -- here is a scenario that produces the problem:

After a cold boot, do:

(setq login-options nil)
(login 'ecc 'ai nil)

The login may actually not be at all necessary.  Note that it is not
running my init, so that's innocent.

Now define the following function:

(defun CHECK-LOGIN-OPTIONS ()
  (declare (special :login-options))
  nil)

And call it -- this is necessary:  the bug only appears when that function, with
its declare, is run:

(check-login-options)

Now define a zwei command:

(zwei:defcom COM-TEST-ONE "..." ()
  (eval '(defstruct (ZERO (:type :list) :conc-name) first))
  zwei:dis-none)

Go into Zwei, install that on Control-}, for example, and then type Control-}.
That will define the ZERO structure and its accessor macro.

Now eval the following:

(macroexpand-1 '(zero-first z))

That should evaluate to (progn (declare (special :login-options)...)
(nth 0 z)).  The bug (I assume it is a bug) is all that declare stuff --
it should just be a simple (nth 0 z).

If, on the other hand, you evaluate that defstruct using the standard
Zwei evaluator, Hyper-Control-E, with (DEFSTRUCT ...) in the buffer, the
bug does NOT happen.  So, what is the difference?  What is wrong with
evaluating inside COM-TEST-ONE when called from Zwei top level key
dispatch?  Just doing (com-test-one) works fine -- you get the bug only
when you type C-} which runs com-test-one.