#1: Doesn't support multiple implementations -----------------------+---------------------------------------------------- Reporter: sburson | Owner: sburson Type: defect | Status: new Priority: major | Milestone: Component: internals | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- You might think, from a cursory glance in `fset.lisp`, that FSet was designed to allow multiple implementations of sets etc., since the interface routines are almost all generic functions. But alas, the promise is not fulfilled; `set`, `bag`, `map`, `seq`, and `tuple` are all concrete classes, with no abstract superclasses. Each of these names should refer to an abstract class, with the current classes made subclasses of these, respectively, and renamed to `wb-set` etc. Three issues, though: () I still want there to be constructor macros named `set` etc. These would select a default representation. (Of course, each concrete class could have its own constructor macro as well.) () The concrete classes are currently structure classes, and I would like to keep them that way; which means the abstract classes will have to be structure classes as well, which means, so must all the other implementations. I don't think this is too big a problem; after all, the additional complexity of standard CLOS objects is to support things like incremental class redefinition, and a collection data structure (particularly a functional one) is unlikely to evolve much once debugged. () I haven't made provision in the operations that combine two collections for specifying a concrete class for the result (like the first parameter of `cl:concatenate`). Seems like the right way to deal with this is to try to choose a reasonable default, and have a keyword parameter to override it. All this said, I'm not really sure how important this is. I have tried to make the FSet implementation fast enough that other implementations would not be needed very often. It's possible one could speed it up a little by dropping features, such as the ability to store equivalent-but-unequal elements, but I wouldn't expect this to yield more than a few percent. It's possible that some other tree structure, such as functional red-black trees, would be a little faster, but again I wouldn't expect more than a few percent -- hardly enough to be worth the trouble. Comments solicited. -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/1> fset <http://common-lisp.net/project/fset> fset