<html><head></head><body>Given that structure accessors can be open coded you need a solution that can force recompilation. You could get that with a build system like asdf. You’d have to remember to rebuild the system instead of just recompiling the defstruct form, but that would work<br> <br><div  class="gmail_signature"><div>-- <br>Robert P. Goldman</div></div> <p class="gmail_quote" style="color:#000;">On July 13, 2022 at 20:40:33, Ville Voutilainen (<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>) wrote:</p> <blockquote type="cite" class="gmail_quote"><span><div><div></div><div>On Thu, 14 Jul 2022 at 00:50, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

<br><blockquote type="cite">

<br>This is what I came up with:

<br>

<br>https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa704a22fc637398e086

<br>

Depending on the value of switch switch sys::*allow-defstruct-redefinition*. In order to allow the structure to be redefined, we delete the structure class, if there is already one.

<br>

<br>The undefined behavior is now

1. use of an existing struct from before the redefinition.

2. creation of functions with the same name as a structure element that has been removed.

3. running existing compiled code that uses an accessor for a slot that has changed relative position in the structure.

<br>

<br>

#2 can be fixed by removing the source transformation for the accessor.

(sys::%set-function-info accessor  nil). It's not hard - involves iterating through the accessors just before the defstruct is redefined.

I don't think I'm going to bother fixing this at the moment.

<br>

#3 can be avoided by (declare (notinline accessor))  in the function being defined. Arguably this is what should be done if (declare (optimize (debug 3))).

I could also have sys::not-inline-p return true if debug is 3. I may try to do this, since it will be easy to forget to recompile.

<br>We could at least provide warnings for such functions if we recorded that the source transform was applied, during compilation

<br>

BTW, if you have an existing (regular) class and create a defstruct with the same name, it blows away the previous class.

That probably deserves a warning.

<br>

Comments welcome.

<br></blockquote>

<br>Greetings from the (for the two decades of it) other side of the

<br>fence, where compilations and one-definition-rules

<br>are rather more static than here. :)

<br>

<br>Sure, this looks plausible, and it probably works in many cases. But

<br>if you COMPILE something with one definition

<br>of a defstruct, then defstruct again, what happens if you try to call

the thing you compiled before?

<br>

<br>I don't claim to claim it "can't work". But I have a vague

understanding why there might be a reason for "this might not work".

<br>:P

<br>

<br>As an unsubstantiated rumination, it might be *more* difficult to make

<br>this work in a language that can do dynamic compilation

<br>at any point in a program than it is in a language that is more static

as far as struct definitions and their compilations are concerned.

<br>My architecture-brain can't tell how you could possibly know where all

<br>the 'references' to the old defstruct could possibly be,

<br>considering that compilations with the old one and uses of those can

<br>be so dynamic, and where the uses that would expect

the newer redefinitions might be, and how you'd track that.

<br>

<br>Again, I'm not saying this can't work. I just find it daunting to even

<br>ponder what sort of funny situations where your program

<br>manages to confuse itself about which struct is which you can end up

<br>with. Maybe that's a theoretical problem, but it hurts my brain. :D

<br>

<br></div></div></span></blockquote></body></html>