Re: Why can't defstructs be redefined?
"Robert P. Goldman" <[email protected]> Wed, 13 Jul 2022 20:47:15 -0500
| Newsgroups | gmane.editors.j.devel |
|---|---|
| Message-ID | <[email protected]> |
--62cf9025_643c9869_4a7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 asd= f. You=E2=80=99d have to remember to rebuild the system instead of just r= ecompiling the defstruct form, but that would work -- =20 Robert P. Goldman =20 On July 13, 2022 at 20:40:33, Ville Voutilainen (ville.voutilainen=40gmai= l.com(mailto:ville.voutilainen=40gmail.com)) wrote: > On Thu, 14 Jul 2022 at 00:50, Alan Ruttenberg <alanruttenberg=40gmail.c= om> wrote: > > =20 > > This is what I came up with: > > =20 > > https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa7= 04a22fc637398e086 > > =20 > > Depending on the value of switch switch sys::*allow-defstruct-redefin= ition*. In order to allow the structure to be redefined, we delete the st= ructure class, if there is already one. > > =20 > > 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 th= at has been removed. > > 3. running existing compiled code that uses an accessor for a slot th= at has changed relative position in the structure. > > =20 > > =20 > > =232 can be fixed by removing the source transformation for the acces= sor. > > (sys::%set-function-info accessor nil). It's not hard - involves iter= ating through the accessors just before the defstruct is redefined. > > I don't think I'm going to bother fixing this at the moment. > > =20 > > =233 can be avoided by (declare (notinline accessor)) in the function= being defined. Arguably this is what should be done if (declare (optimiz= e (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. > > We could at least provide warnings for such functions if we recorded = that the source transform was applied, during compilation > > =20 > > BTW, if you have an existing (regular) class and create a defstruct w= ith the same name, it blows away the previous class. > > That probably deserves a warning. > > =20 > > Comments welcome. > =20 > Greetings from the (for the two decades of it) other side of the > fence, where compilations and one-definition-rules > are rather more static than here. :) > =20 > Sure, this looks plausible, and it probably works in many cases. But > if you COMPILE something with one definition > of a defstruct, then defstruct again, what happens if you try to call > the thing you compiled before=3F > =20 > I don't claim to claim it =22can't work=22. But I have a vague > understanding why there might be a reason for =22this might not work=22= . > :P > =20 > As an unsubstantiated rumination, it might be *more* difficult to make > this work in a language that can do dynamic compilation > 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. > My architecture-brain can't tell how you could possibly know where all > the 'references' to the old defstruct could possibly be, > considering that compilations with the old one and uses of those can > be so dynamic, and where the uses that would expect > the newer redefinitions might be, and how you'd track that. > =20 > Again, I'm not saying this can't work. I just find it daunting to even > ponder what sort of funny situations where your program > manages to confuse itself about which struct is which you can end up > with. Maybe that's a theoretical problem, but it hurts my brain. :D > =20 --62cf9025_643c9869_4a7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head></head><body>Given that structure accessors can be open coded= you need a solution that can force recompilation. You could get that wit= h a build system like asdf. You=E2=80=99d have to remember to rebuild the= system instead of just recompiling the defstruct form, but that would wo= rk<br> <br><div class=3D=22gmail=5Fsignature=22><div>-- <br>Robert = P. Goldman</div></div> <p class=3D=22gmail=5Fquote=22 style=3D=22color:=23= 000;=22>On July 13, 2022 at 20:40:33, Ville Voutilainen (<a href=3D=22mai= lto:ville.voutilainen=40gmail.com=22>ville.voutilainen=40gmail.com</a>) w= rote:</p> <blockquote type=3D=22cite=22 class=3D=22gmail=5Fquote=22><span= ><div><div></div><div>On Thu, 14 Jul 2022 at 00:50, Alan Ruttenberg <a= lanruttenberg=40gmail.com> wrote: <br><blockquote type=3D=22cite=22> <br>This is what I came up with: <br> <br>https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa7= 04a22fc637398e086 <br> <br>Depending on the value of switch switch sys::*allow-defstruct-redefin= ition*. In order to allow the structure to be redefined, we delete the st= ructure class, if there is already one. <br> <br>The undefined behavior is now <br>1. use of an existing struct from before the redefinition. <br>2. creation of functions with the same name as a structure element th= at has been removed. <br>3. running existing compiled code that uses an accessor for a slot th= at has changed relative position in the structure. <br> <br> <br>=232 can be fixed by removing the source transformation for the acces= sor. <br>(sys::%set-function-info accessor nil). It's not hard - involves ite= rating through the accessors just before the defstruct is redefined. <br>I don't think I'm going to bother fixing this at the moment. <br> <br>=233 can be avoided by (declare (notinline accessor)) in the functio= n being defined. Arguably this is what should be done if (declare (optimi= ze (debug 3))). <br>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> <br>BTW, if you have an existing (regular) class and create a defstruct w= ith the same name, it blows away the previous class. <br>That probably deserves a warning. <br> <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= <br>the thing you compiled before=3F <br> <br>I don't claim to claim it =22can't work=22. But I have a vague <br>understanding why there might be a reason for =22this might not work=22= . <br>:P <br> <br>As an unsubstantiated rumination, it might be *more* difficult to mak= e <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 stati= c <br>as far as struct definitions and their compilations are concerned. <br>My architecture-brain can't tell how you could possibly know where al= l <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 <br>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 eve= n <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> --62cf9025_643c9869_4a7--