Hi

Maybe you will not know it but bit vectors are sometimes a very good match
to represent sets where the world is defined from the beginning. a world of
64 objects can represent subsets of this world as a uint64_t in other words
the unit our cpu's are so darn fast at managing.  So whenever you plan to
spend time on having sets of a moderate set of enums an huge
optimisation is to not use a hashmap, but n stead use a bitvector. And as
you know, guile ave arbitrary big integers so a world of 128 elements is
just a  quite small bignum. Now this does not scale to millions where
hashmaps starts to excel, but many times you do not need scale.
Now what about our favorite set operations you may ask? well we have a
translation here

set complement = lognot
set union            = logior
set intersection  = logand
set addition        = lugxor

And the processor have ops for even some other set operations like finding
the first nonzero bit
in order to loop through the elements in the set that are 1 (this would be
a good addition
to guile).

In guile-log I have implemented a very featureful prolog matcher on
steroids where the bulk of the work is to manage the set of matching
elements, where all set operations are used. And is hence super fast for
typical implemented predicates as this includes typically have less than 64
cases.  So if the number of match cases is below 1000 we typically just
keep a bigint to represent the set else we move over to hashmaps. Now
un-fourtunately in guile, we do not have self modifying bitwise operators
so in guile-log I hack guile i C to have those ops to not waste
a lot of memory and time for larger predicates with bigger bit vectors.

This is why I hope that guile will keep having big sized immediate integers
as  copying is so cheap and fast (creating new numbers on the stack).

When working with supervectors I realized that a functional approach is
sort of viable as we can share bits between different read only structures
and even use copy on write if we would
like to mutate.
Using  a supervector approach to bitvectors make sense if we would like to
move to higher sizes as well and is much preferable than using hashmaps. we
would represent the sets by trees instead which spervectors essentially
are. So I realized that there is a good use case for these kinds of data
structures in a supervector context and hence I am working on this atm.

Kind of cool is that I keep a bit representing if the bin is negated or
not, which means that we can optimize essentially all set operations of the
type sparse-bitvector Op fat-bitvector her is how it goes.

lognot  -> just iterate through the bins and change the invert bit
1 or Bitvector    => 1
0 or Bitvector    => Bitvector

1 and Bitvector => Bitvector
0 and Bitvector => 0
1 xor  Bitvector => lognot(Bitvectoe)
0 xor  Bitvector => Bitvector

cool right. Now the code in stis-supervectors can handle all cases, if the
bins are not aligned and try to be smart about it (can treeify a
datastructure to match bins) so it is a more complex story here, but in the
simplest setup we just have a vector of bins with all bins the same size
and we are good to go. A hint is to use binsizes of (ash 1 x), x a number
so that we enable the easiest way to match bins else it can be really
fragmented.

A final note:
Why on earth does not guile's bitvectors allow more bitwise operations,
looks qiuite a bit of underpowered to me.