[m-rev.] for review: pretty-printing sparse bitsets

[Zoltan Somogyi]

On Mon, 22 Sep 2025 15:54:15 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> On Sun, 21 Sept 2025 at 22:26, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> > The implementation is straightforward, the review is more for
> > how to present the new formatters to users, given that these
> > are "lossy" formatters. (They do not print the values in the given set;
> > they print only to result of applying the to_uint method to those values.)
> >
> > I can see the following ways.
> >
> > 1. Simply add the formatters of the bitset types to the default formatter map.
> >
> > 2. Keep them out of the default formatter map, but add a predicate that
> >     adds themall  to that map.
> >
> > 2a. Make this new predicate a public part of the pretty_printer.m's interface;
> > 2b. Make this new predicate a private part of the interface, i.e. put in a second interface section that is not included in the manual.
> >
> > 3. Export the fmt_*_bitset functions, and let users call set_formatter with them.
> >
> > My order of preference is the one above: 1, 2a, 2b and 3. What's yours?
> 
> I think (1) is fine, users can always override the behaviour if necessary.
> (That said, the documentation for {get,set}_default_formatter_map needs
> to mention that there are formatters for the bitset types registered
> by default.)

Ok, I added such a mention.

But in the process, I found that the last part of the comment says that
the default formatter map is thread local. For at least the C backend,
I don't see that being true, since we store the map in a global variable.
Do you know the story behind that?

Zoltan.