June 2007 - fset-ticket@lists.common-lisp.net

[fset-ticket] #1: Doesn't support multiple implementations
by fset 25 Jul '07

25 Jul '07

#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 2

[fset-ticket] #4: Need tests for CL compatibility functions
by fset 11 Jun '07

11 Jun '07

#4: Need tests for CL compatibility functions -----------------------+---------------------------------------------------- Reporter: sburson | Owner: sburson Type: testing | Status: new Priority: major | Milestone: 1.1 Component: internals | Version: Keywords: | -----------------------+---------------------------------------------------- The CL compatibility functions (that is, the generic versions of the CL sequence functions -- `find` etc.) need to be tested in the test suite. (I have hand-tested them, but a test that could be re-run after changes would be better.) -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/4> fset <http://common-lisp.net/project/fset> fset

1 0

[fset-ticket] #3: Tuple test should be multithreaded
by fset 11 Jun '07

11 Jun '07

#3: Tuple test should be multithreaded -----------------------+---------------------------------------------------- Reporter: sburson | Owner: sburson Type: testing | Status: new Priority: major | Milestone: 1.1 Component: internals | Version: Keywords: | -----------------------+---------------------------------------------------- Tuples are the only FSet datatype whose implementation involves shared data structures. A multithreaded test is in order. -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/3> fset <http://common-lisp.net/project/fset> fset

1 0

[fset-ticket] #2: Review test suite for completeness
by fset 11 Jun '07

11 Jun '07

#2: Review test suite for completeness -----------------------+---------------------------------------------------- Reporter: sburson | Owner: sburson Type: testing | Status: new Priority: major | Milestone: 1.1 Component: interface | Version: Keywords: | -----------------------+---------------------------------------------------- Review the test suite to see if there are any interfaces that are not tested (there are probably a few). Add tickets here for any you find. -- Ticket URL: <http://trac.common-lisp.net/fset/ticket/2> fset <http://common-lisp.net/project/fset> fset

1 0