This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
ian@bickiia.earlhall.earlham.edu writes: > > I don't see any actual reason for association lists except > compatability. A hash-table should mimic all the association list > behavior. Unfortunately, if you make sequence functions act like (1) > you won't get this alist like behavior, you'll need seperate functions > that act on the associations. Not a big deal, but then hash-tables > wouldn't be drop-in replacements for alists. > I recently thought about what advantages lists have over vectors, and correspondingly, what advantages alists would have over hash tables. The most compelling reasons I thought of: * Very cheap to insert if you don't care about ordering (just insert at the head). * Much cheaper to filter. * More generally, inserting, deleting, or any length-changing operations are cheaper. This is true to some degree even of non-destructive versions, IMO, because you have to traverse the data twice, once to compute the size for the new vector, and again to actually do the computation. So I think both list-like and vector-like data structures must be provided, since they each have adcantages in different contexts. However, I'm not sure these are enough to make lists preferable to vectors for all the applications in which they are used - I think this is largely due to a lack in Scheme of as rich a set of standard and traditional libraries for vectors as there are for lists. Hopefully the RFI process can help address this. In fact, I might try my hand at writing a corresponding vector version of Olin Shivers' list library SRFI proposal. CL-like generic sequence functions are a plausible next step, but one that should be taken more cautiously - Scheme has a long history of avoiding polymorphic functions of this kind, and there is some good reasoning behind those design decisions. > The other place where alists are different is being able to construct > them manually, e.g.: > > '(('key1 . "value1") > ('key2 . "value2")) > > I think allowing this is a bad thing anyways. An alist is only > distinguished from a list in concept, not in type. My recent work > with Tcl (which does this for everything) makes me think this is a bad > idea because it cripples the ability for the language implementation > to be intelligent and undoes some of the advantages of dynamic typing. Being able to treat alists as normal lists is very useful in some contexts, however. Sometimes you want to manipulate the alist ignoring the fact that it consists of key-value pairs. - Maciej