Closed jackfirth closed 2 years ago
Remaining tasks for sorted sets:
unmodifiable-sorted-set
wrapper for read-only access to mutable sorted setssynchronized-sorted-set
wrapper for thread-safe access to mutable sorted setsmanaged-sorted-set
wrapper for kill-safe access to mutable sorted setssorted-set-impersonate
for chaperones and impersonatorssorted-set/c
contract combinatorsorted-subset
that don't use the same comparator as the sorted setsorted-set-reverse
is an involutionsorted-subset
with unbounded-range
is an identity operationsorted-subset
is idempotentunmodifiable-sorted-set
is idempotentsynchronized-sorted-set
is idempotentmanaged-sorted-set
is idempotentI'm going to merge this as-is since it's already huge. All the basics for sorted sets are there sans detection of modification during iteration. I'll work on sorted maps next, since multisets, range sets, and range maps are all just views of sorted maps.
This is a work-in progress change that will add mutable and immutable sorted collections to Rebellion, including:
The immutable collections will also come with builders, which support the use case of building a collection up with many writes before any reads are performed (such as in a stream pipeline, e.g.
(transduce numbers #:into (into-sorted-set natural<=>))
. When created with builders, the immutable collections will not use a persistent representation under the hood to support constant-time random access and efficient iteration. Instead, the persistent representation will be created lazily the first time an immutable collection is used with the persistent update functions such assorted-set-add
. This combines the best of both worlds: use cases that don't need to interleave reads and writes get efficient random-access immutable collections, and use cases that do have their immutable collections upgraded to persistent collections automatically.Lots of implementation work left to do.
In particular, I still need to figure out how to represent subset views efficiently, especially for mutable collections.Also, the mutable collections won't be thread-safe but will provide fail-fast behavior on concurrent modification during iteration, like java'sConcurrentModificationException
. This is too useful for detecting data races to ignore. In the future I may consider offering alternative thread-safe implementations, but the default mutable collection implementations won't change.