[fset-ticket] #1: Doesn't support multiple implementations

#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

#1: Doesn't support multiple implementations ------------------------+--------------------------------------------------- Reporter: sburson | Owner: sburson Type: defect | Status: assigned Priority: major | Milestone: 1.1 Component: internals | Version: 1.0 Resolution: | Keywords: ------------------------+--------------------------------------------------- Changes (by sburson): * milestone: => 1.1 * status: new => assigned Comment: Fixed; the fixed will be released in 1.1. -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/1> fset <http://common-lisp.net/project/fset> fset

#1: Doesn't support multiple implementations ------------------------+--------------------------------------------------- Reporter: sburson | Owner: sburson Type: defect | Status: closed Priority: major | Milestone: 1.1 Component: internals | Version: 1.0 Resolution: fixed | Keywords: ------------------------+--------------------------------------------------- Changes (by sburson): * resolution: => fixed * status: assigned => closed Comment: Fix released. -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/1> fset <http://common-lisp.net/project/fset> fset
participants (1)
-
fset