#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
