Why can't defstructs be redefined?

[Alan Ruttenberg]

On Wed, Jul 13, 2022 at 10:53 PM Ville Voutilainen <
ville.voutilainen at gmail.com> wrote:

> On Thu, 14 Jul 2022 at 05:33, Alan Ruttenberg <alanruttenberg at gmail.com>
> wrote:
> >
> > Comments inline
> > Seems to work, as long as you don't allow the source transform.
> Currently I'm experimenting with a new option to defstruct. So
> >
> > I compile a file with
> > (defstruct (test2 (:optimize nil)) a b)
>
> I'm thinking I'm stupid, since I'm not sure what you mean by "source
> transform",


ABCL has a mechanism for source transformations, which effectively inline
some code instead of calling a function. You can get a source
transformation with
sys:function-info. For example:

(sys::function-info my-accessor)
((:source-transform . #<anonymous-function
abcl_b09e0b54_a7c4_4513_86e6_fd9effb1fb25 {27C03870}>))

These are applied in the compiler and aren't affected, currently, by the
(declare (optimize ..)) settings. They are used for defstruct in
define-reader and define-writer.

The implementation I discuss is here:
https://github.com/alanruttenberg/abcl/commit/a9c5541d372012d24c0daa704a22fc637398e086

but I can with fair confidence say that if
> you can ensure that all defstructs use the option you add as a
> custom-thingy, then the rest of the concerns I spoke of
> are moot. :P You're basically saying "this is not a regular defstruct,
> it's a special one, don't do the usual stuff, and then
> I can make it mean whatever I want it to mean, side-stepping the
> problems". If that works for your use cases, sure,
> seems plausible in general. Or have I misunderstood your approach?
>

Sort of. There's no usual stuff around redefining defstructs, so it's more
of an added feature. It is implementation dependent, but then so is JSS
which I understand many people find useful.  I'm hoping it would be useful
for anyone who needs to develop defstructs during initial code writing and
testing. It doesn't change any behavior if you don't use the option, so
it's safe. It's not a perfect solution, but the perfect is the enemy of the
good. I will keep thinking about whether there's a way to remove the
potential gotchas.

FWIW, my use case is developing some code using lisp-binary
<https://github.com/j3pic/lisp-binary>(super useful for parsing binary
files). It generates defstructs with some extra code around them.
But since I don't know it well enough I'm still making mistakes and needing
to redefine things. Before this change the only option was to restart lisp
if I made a mistake, which gets old quickly.  If I had my druthers,
lisp-binary would have generated classes instead of defstructs, since there
are no problems with redefinitions there. I may try to modify lisp-binary
to do that at some point...

There's a more conservative approach which fits better with "regular"
defstruct usage, which is to allow adding slots to defstruct, but not
reordering or deleting. Even that can't be done now. I started to implement
that, which wouldn't need as much care to use it. But it turned out that
just wasn't enough for the development I was doing now. Not having even
that capability has burned me in the past.

YMMV.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20220713/14e3d5b8/attachment.html>