From: Neil Heffernan
Subject: Lispworks Bug? Relating to Using setf with a structure.
Date: 
Message-ID: <3B016ACC.E5294CBD@cs.cmu.edu>
I have been using Lispworks for over a year and just cam across what I
think is a bug but I don't know why it is happening.

Its seems to relate to using setf on a structure.

I have a call like
(setf (structureName-structureField object) 'some_new_value)
and lispworks will sometimes throw an error

Undefined function "SETF structureName-structureField".
   Note- Missing parentheses between the setf and the structureName.

Anyone have an ideas?  What is odd, is that I use a lot of structures
set things in them all over the place, but now on two seperate
structures aI have recived error messages like this.

Thanks
    Neil
Carnegie Mellon Univeristy
Post-Doc
····@cs.cmu.edu

From: Kent M Pitman
Subject: Re: Lispworks Bug? Relating to Using setf with a structure.
Date: 
Message-ID: <sfwofsuqy7j.fsf@world.std.com>
Neil Heffernan <····@cs.cmu.edu> writes:

> 
> I have been using Lispworks for over a year and just cam across what I
> think is a bug but I don't know why it is happening.
> 
> Its seems to relate to using setf on a structure.
> 
> I have a call like
> (setf (structureName-structureField object) 'some_new_value)
> and lispworks will sometimes throw an error
> 
> Undefined function "SETF structureName-structureField".
>    Note- Missing parentheses between the setf and the structureName.

Ignore this part of the issue.  Some functions have compound names like
(setf foo), but some Lisp implementations store the functional values
of such functions in generated symbol names that are mostly supposed to
remain hidden, but that show up in some error messages.  This is a user
interface bug, but no sign of anything wrong in and of itself.

> Anyone have an ideas?  What is odd, is that I use a lot of structures
> set things in them all over the place, but now on two seperate
> structures aI have recived error messages like this.

You're probably doing a forward reference to something that later gets
defined in a macro-like way.  When you compile
 (setf (never-saw-this-before x) y)
you will  not get an error but will rather get the same as

 (let ((temp-x x)  ;this LET preseves left-to-right order of evaluation
       (temp-y y))
   (funcall #'(setf never-saw-this-before) temp-y temp-x))

You can later do

 (defun (setf never-saw-this-before) (new-value x)
   ... put the new-value somewhere keyed by x...)

and your code will work.  But you CANNOT later do

 (defsetf never-saw-this-before ...)
nor
 (define-setf-method never-saw-this-before ...)

I'm not sure without looking, and too lazy to look now, but you might or
might not also be forbidden from doing

 (setf (never-saw-this-before ...) ...)

prior to the a definition like:

 (defstruct never-saw 
   this-before)

In general, I would advise you to always 
 (a) have your defstruct precede its accessor uses
 (b) make sure your compilation script always loads the defstruct
     prior to compiling uses.

You might think (b) was implied by (a) but many DEFSYSTEM implementations
work hard to compiler and/or load only those files which they "have to"
before compiling the files that have changed.  They rely critically on your
having told them correct information about definitional dependencies in order
to avoid just doing (mapcar #'(lambda (x) (compile (load x))) ...)
which might involve a lot more compiling and/or loading that is needed.  But
in so doing, they create a lot of chances to fake yourself out into thinking
that file A, just because it precedes file B in the defsystem will actually
always be loaded before B.  When it's not, the compiler will assume the
forward-reference behavior I'm describing and you will later lose.

A similar thing happens if you compile a macro call before its use.  The
system will assume it's a reguular function, and you can later define such
a function and it will be fine.  But if you have to define it as a macro,
you will (as a famous Symbolics Genera error message used to tell you when
it saw an incompatible definition happening after it had acted on an 
improper assumption) "indubitably lose".
From: Tim Bradshaw
Subject: Re: Lispworks Bug? Relating to Using setf with a structure.
Date: 
Message-ID: <ey3u22m1kqp.fsf@cley.com>
* Kent M Pitman wrote:
> I'm not sure without looking, and too lazy to look now, but you might or
> might not also be forbidden from doing

>  (setf (never-saw-this-before ...) ...)

> prior to the a definition like:

>  (defstruct never-saw 
>    this-before)

The hyperspec says: 

        The mechanism by which defstruct arranges for slot accessors
        to be usable with setf is implementation-dependent; for
        example, it may use setf functions, setf expanders, or some
        other implementation-dependent mechanism known to that
        implementation's code for setf.

So I think all bets are off for portable code.

My LW definitely doesn't like it.

--tim