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

[fset]

#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