Re: Why can't defstructs be redefined?
Stas Boukarev <[email protected]> Thu, 14 Jul 2022 02:48:16 +0300
| Newsgroups | gmane.editors.j.devel |
|---|---|
| Message-ID | <CAF63=11=hOj2MxhUPEgiv0Hcf_4RXi-hJeTXUik-af8CQi6e7g@mail.gmail.com> |
Instead of sys::*allow-defstruct-redefinition* it could be a restart. On Thu, Jul 14, 2022 at 12:50 AM Alan Ruttenberg <[email protected]> wrote: > > This is what I came up with: > > https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa704a22fc637398e086 > > 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. > > 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. > > > #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. > > #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. > We could at least provide warnings for such functions if we recorded that the source transform was applied, during compilation > > 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. > > Comments welcome. > > Alan > > > On Tue, Jul 12, 2022 at 3:44 AM Vibhu Mohindra <[email protected]> wrote: >> >> On 11/07/2022 19:41, Alan Ruttenberg wrote: >> > Anyone know this area of the compiler? It's very frustrating during >> > development. >> >> Interesting. The rationale is performance apparently. >> CLTL2: 19.2. How to Use Defstruct >> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node170.html >> whose last four paragraphs explain the reason. It concludes with: >> "The defstruct feature is intended to provide ``the most efficient'' >> structure class. CLOS classes defined by defclass allow much more >> flexible structures to be defined and redefined." >> >> ---- >> If you want flexibility, but also don't want to use classes instead of >> structs everywhere, one solution may be to define your own defstruct >> macro in some package that produces a class and functions/methods. >> Import and use that defstruct during development, but switch over to the >> real one when development ends (assuming you want its performance). >> >> > Seems we ought to, at least, be able to blow away all >> > traces of the defstruct, ignoring existing structures and redefine it. >> >> CLTL2 above agrees in its last para, >> "Programming environments are allowed and encouraged to permit defstruct >> redefinition, [...]" >> so it sounds like you'll have made ABCL better once your >> structure-definition approach succeeds. Others on this list will know >> more about this area and the errors you're seeing. >> >> Vibhu >>