From fset-devel at common-lisp.net Thu Jun 7 05:10:44 2007 From: fset-devel at common-lisp.net (fset) Date: Thu, 07 Jun 2007 05:10:44 -0000 Subject: [fset-ticket] #1: Doesn't support multiple implementations Message-ID: <074.d3a641b7663a8661900b9f16df0afc2f@common-lisp.net> #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: fset fset From fset-devel at common-lisp.net Mon Jun 11 03:04:28 2007 From: fset-devel at common-lisp.net (fset) Date: Mon, 11 Jun 2007 03:04:28 -0000 Subject: [fset-ticket] #2: Review test suite for completeness Message-ID: <074.380070090be6d437b31cde8d40117dcc@common-lisp.net> #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: fset fset From fset-devel at common-lisp.net Mon Jun 11 03:07:32 2007 From: fset-devel at common-lisp.net (fset) Date: Mon, 11 Jun 2007 03:07:32 -0000 Subject: [fset-ticket] #3: Tuple test should be multithreaded Message-ID: <074.af1ce0a78128c89152cb39243fdf5f36@common-lisp.net> #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: fset fset From fset-devel at common-lisp.net Mon Jun 11 03:29:04 2007 From: fset-devel at common-lisp.net (fset) Date: Mon, 11 Jun 2007 03:29:04 -0000 Subject: [fset-ticket] #4: Need tests for CL compatibility functions Message-ID: <074.264ecc19ab7dad1d0e1743ffe9c4474d@common-lisp.net> #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: fset fset