Why can't defstructs be redefined?
stassats at gmail.com
Wed Jul 13 23:48:16 UTC 2022
Instead of sys::*allow-defstruct-redefinition* it could be a restart.
On Thu, Jul 14, 2022 at 12:50 AM Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> This is what I came up with:
> 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.
> On Tue, Jul 12, 2022 at 3:44 AM Vibhu Mohindra <vibhu.mohindra at gmail.com> 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
>> 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.
More information about the armedbear-devel