DEFVST

[Jonathan A. Rees <REES at MIT-MC>]

    Date: 14 March 1980 23:37-EST
    From: Edward Barton <EB at MIT-AI>
    To:   BUG-LISP at MIT-AI
    Re:   DEFVST

    What is the proper way to make DEFVST constructions intelligible
    to the compiler but unavailable at runtime?
       (eval-when (compile) (defvst barf a b c))
       (defun foo () (cons-a-barf a 1 b 2 c 3))
    seems reasonable, but this causes the result of (FOO) to produce
    a hunk whose struct-typep is nil and which contains "UNBOUND"
    for at least one component. 

What you want to say is not (eval-when (compile) (defvst ...)), but
simply (defvst ...), at top level in your file.  This will make sure
that the information that struct-typep wants to look at is available
at runtime, and should fix the problem of whatever it was being
UNBOUND.  I notice that since you use struct-typep, you need to have
DEFVST around at runtime; you might make sure it's loaded before your
defvst is encountered by the loader.  Use an incantation such as
  (eval-when (eval load compile)
    (cond ((status nofeature DEFVST) (load '((lisp) defvst))))) 
instead of letting struct-typep autoload, if that's what you're doing.

I'm not sure what you mean by 'DEFVST constructions', but
if you mean that you don't want the macros cons-a-barf, barf-a, etc.
to get output to the FASL file, just do
  (eval-when (compile)
    (setq defmacro-for-compiling () defmacro-displace-call ()))
before the top level occurrence of defvst (but if you have other DEFMACROs
you do want compiled, be sure to reset these magic variables to T).  (Too
bad the Maclisp compiler doesn't have COMPILER-LET, which would be the
right way to bind those flags!)