Re: Circular records: how do I best handle them? (The new correct warning position branch now bootstraps in native compilation!)

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sat, Jan 01, 2022 at 12:31:51 -0500, Stefan Monnier wrote:

[ .... ]

> > What I bumped into was circularly linked vectors in the source code
> > being compiled.

> Then my question above turns into: what is this source code?

> > I've amended the reader so that it doesn't put positions on symbols
> > which are read as components of other structures such as byte compiled
> > functions, text property lists in strings, and so on.  (Actually, there
> > was very little to amend.).

> OK.

> >> > The positions get stripped before the code is dumped to the .elc.
> >> Why bother?  You can just have a `print-symbols-without-position` which
> >> you let-bind around the printing code.
> > I think I've got that already, though it's a long time since I looked at
> > it.

> So why do you need to strip the positions before dumping the code into
> the `.elc`?

Thank you very much indeed for this tip.  I don't need to strip the
positions.  eval already handles symbols with position (provided
symbols-with-pos-enabled is non-nil), as does pretty much everything
else, including the native-compiler.

Binding that variable and print-symbols-bare to non-nil rather than
stripping positions was actually quite simple, compared with the mess I
was in trying to deal with the circularity in some of the
lists/vectors/records.  I profiled some of the compilation runs with the
stripping strategy, and garbage collection was consuming around 70% of
the run time.  :-(

I've now got the thing working modulo tidying up.  A make bootstrap now
takes 7min 45sec on my machine, compared with 7min 18sec for the same on
the master branch.  That's a 7% difference.  However, I've still got to
strip out the old warning position mechanism, which should shave
something off of that 7% difference.

[ .... ]

> `put` and `puthash` are just some of the ways a macro's arg can
> "escape".  A macro may also something like

>     (push arg my-list-of-stuff)

> Having to strip symbol positions in `put` and `puthash` (i.e. having
> this implementation detail leak to those places which aren't directly
> related to compilation) is pretty ugly.  Do we really want to extend
> that to `setq`, `aset`, and whatnot?

No.  What we have to do is NOT to strip positions off of these objects,
instead warning users to be careful about saving bits of code in a way
that survives the byte compilation.  Possibly we should give them the
position stripping function to use at their discretion.  What do you
think?

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).