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

[Zoltan Somogyi]

On Mon, 22 Sep 2025 19:48:11 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Mon, 22 Sept 2025 at 18:51, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> > 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?
> 
> The default formatter map was originally stored in a thread-local mutable,
> so the documentation was accurate when this module was written.
> Ralph changed that in commit ceb64e8c in an attempt to avoid module
> ordering problems when using :- initialise directives to populate the default
> formatter map.  (I suspect the removal of the thread-local aspect may have
> been inadvertent.)

But after commit 5cbcfaa0edfc1b784ce4e33cdef29b3ac7a6392e,
which moved the type-specific format operations to pretty_printer.m itself,
that ordering problem should have disappeared wrt the standard library,
though it may remain wrt user-written modules.

On the other hand, I don't use multi-thread code myself, so I don't know
what use cases there are for thread-specific formatter maps. I really can't
think of any, given that put_doc allows any call that needs a specific formatter
map to specify that map itself.

My question is: should we fix the code to make the default formatter map
thread-local, or should we delete the false claim that it *is* thread-local? I don't
really care one way or the other, but I think the contradiction should be resolved.

BTW, please don't touch pretty_printer.m itself for the next day or two,
as I am working on it.

Zoltan.