- fset-ticket@lists.common-lisp.net - mailman3.common-lisp.net

[fset-ticket] Remove and siblings incomplete
by thomas.bartscher＠googlemail.com 01 Apr '13

01 Apr '13

The methods for sets of REMOVE, REMOVE-IF and REMOVE-IF-NOT don't seem to be implemented. I didn't check for other types in FSet.

1 0

[fset-ticket] Unexpected behaviour of SEQ class
by thomas.bartscher＠googlemail.com 12 Nov '12

12 Nov '12

The documentation says "A seq can hold character strings interspersed with occasional non-characters quite efficiently; each non-character will force only one leaf vector to be a non-string. (Similarly, a seq can hold strings of base-chars interspersed with the occasional extended-char quite efficiently.)" The problem is that the following code fails nevertheless: (defun test () (let* ((seq (seq 1 #\a)) (str-seq (seq #\a)) (seq2 (subseq seq 1))) (format t "(equal str-seq seq2) => ~A~%" (equal? str-seq seq2)) (format t "(format nil \"...\" (convert 'string str-seq)) => ~A~%" (format nil "~A" (convert 'string str-seq))) (format t "(format nil \"...\" (convert 'string seq2)) => ~A~%" (format nil "~A" (convert 'string seq2))))) This is because the contents of the SEQ sequence are stored as a vector with element-type T, SUBSEQ on SEQ doesn't change the vector into a string and (CONVERT 'STRING ...) checks whether the contents of any SEQ are stored as a string and returns an error otherwise. The resulting error message isn't very helpful either: The value NIL is not of type CHARACTER. [Condition of type TYPE-ERROR] I forgot where the NIL comes from but this isn't obviously connected to the invocation of (CONVERT 'STRING ...) on SEQ in any way. It get's even worse because SEQ doesn't contain NIL anywhere. I don't know much about optimization so I am reluctant in trying to write a fix.

1 0

[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