<div dir="ltr"><div>This is what I came up with:</div><div><br></div><div><a href="https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa704a22fc637398e086">https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa704a22fc637398e086</a></div><div><br></div><div>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.</div><div><br></div><div>The undefined behavior is now</div><div> 1. use of an existing struct from before the redefinition. <br></div><div> 2. creation of functions with the same name as a structure element that has been removed.  <br></div><div> 3. running existing compiled code that uses an accessor for a slot that has changed relative position in the structure.</div><div><br></div><div><br></div><div>#2 can be fixed by removing the source transformation for the accessor.</div><div>(sys::%set-function-info accessor  nil). It's not hard - involves iterating through the accessors just before the defstruct is redefined.</div><div>I don't think I'm going to bother fixing this at the moment.<br></div><div><br></div><div>#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))).</div><div>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></div><div>We could at least provide warnings for such functions if we recorded that the source transform was applied, during compilation</div><div><br></div><div>BTW, if you have an existing (regular) class and create a defstruct with the same name, it blows away the previous class. <br></div><div>That probably deserves a warning.<br></div><div><br></div><div>Comments welcome.</div><div><br></div><div>Alan<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 12, 2022 at 3:44 AM Vibhu Mohindra <<a href="mailto:vibhu.mohindra@gmail.com">vibhu.mohindra@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/07/2022 19:41, Alan Ruttenberg wrote:<br>
> Anyone know this area of the compiler? It's very frustrating during <br>
> development.<br>
<br>
Interesting. The rationale is performance apparently.<br>
CLTL2: 19.2. How to Use Defstruct<br>
<a href="https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node170.html" rel="noreferrer" target="_blank">https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node170.html</a><br>
whose last four paragraphs explain the reason. It concludes with:<br>
"The defstruct feature is intended to provide ``the most efficient'' <br>
structure class. CLOS classes defined by defclass allow much more <br>
flexible structures to be defined and redefined."<br>
<br>
----<br>
If you want flexibility, but also don't want to use classes instead of <br>
structs everywhere, one solution may be to define your own defstruct <br>
macro in some package that produces a class and functions/methods. <br>
Import and use that defstruct during development, but switch over to the <br>
real one when development ends (assuming you want its performance).<br>
<br>
> Seems we ought to, at least, be able to blow away all <br>
> traces of the defstruct, ignoring existing structures and redefine it.<br>
<br>
CLTL2 above agrees in its last para,<br>
"Programming environments are allowed and encouraged to permit defstruct <br>
redefinition, [...]"<br>
so it sounds like you'll have made ABCL better once your <br>
structure-definition approach succeeds. Others on this list will know <br>
more about this area and the errors you're seeing.<br>
<br>
Vibhu<br>
<br>
</blockquote></div>