If you are using a collection class that is neither built in to Common Lisp nor part of FSet, and you want to use instances of the class in such a way that FSet will need to compare or hash them (see Which Elements are Compared or Hashed), you have a bit more work to do.
First, you need to decide whether to treat them as value types or reference types. If they are mutable, I recommend treating them as reference types if (a) you can find a way to do that and (b) doing so makes sense, given the way you want to use them; but it’s possible that you’ll want to treat them the same way FSet treats CL lists and vectors: by assuming that they won’t be mutated once they’re placed in an FSet collection, so that you can compare and hash them by content. If you make that assumption, don’t forget to stick to it!
You have another choice as well: whether to implement the comparison and hashing by adding methods
to compare and hash-value, or by defining custom comparison and hash functions to be
used with the collections that contain instances of this class. I recommend the former, as
it’s more convenient and the generic function dispatch overhead is unlikely to be significant, but
it’s up to you.
Either way, you’ll need to understand the previous section. For
examples, see the compare methods in the FSet source tree, file Code/order.lisp.
There are two further choices to be made about the hash function: whether to do bounded hashing, and whether to cache the result. For collections that can get large, I recommend doing at least one of them. Bounded hashing keeps the hashing time from getting out of hand; as mentioned above, FSet can live with the risk of a higher hash collision rate because it falls back to using WB-trees for the collision sets. Caching takes a different approach; the initial hash computation can be expensive, but it only needs to be done once per collection instance. Which of these is better for a given collection class will depend on the details of how the class is to be used.