Re: Scheme is too complicated

[Maciej Stachowiak <mstachow@mit.edu>]

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