Re: [Sbcl-commits] master: Make a few mostly-stylistic tweaks to macro char reading

I can't resist pointing out that there are newer data structures that solve
the iterator problem nicely.  A mutable wrapper around a persistent
functional map provides the familiar mutable semantics while being fully
iteration-safe.  Readers never have to be locked at all, and iterators see
only a snapshot as of the start of iteration.  (Writers still have to be
locked against each other, of course.)  The only location that is ever
written more than once is the one holding the pointer to the root of the
internal tree.

I have prepared an implementation of Michael Steindorfer's CHAMP hash
tables similar to the one I have written for FSet, boiled down to contain
only the parts you would need.  Performance is certainly acceptable for
this application.  Have a look:
https://gitlab.common-lisp.net/sburson/champ-lite

-- Scott

On Mon, Nov 10, 2025 at 6:12 AM Douglas Katzman via Sbcl-devel <
[email protected]> wrote:

> I would boil this down to: I do not want to expose an iterator where I can
> provide no guarantees around how such an iterator would behave in this or
> that situation? Call it paranoia over handing out an access path to some
> internals that could fundamentally break READ without an extremely strong
> contract in place about what you'll do with the iterator, Except I also
> don't want to know what would be in that contract.
>
> Could we do instead of my previous suggestion, just (readtable-list-defined-macro-characters
> rt) that returns a list of characters currently defined to have macros ?
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel