Re: [Chicken-users] Alist versus Hash-table

[Peter Bex]

On Tue, Nov 12, 2013 at 09:24:23AM -0500, John Cowan wrote:
> Peter Bex scripsit:
> 
> > alist-update will take O(n) to locate the key just like alist-update!,
> > but when it finds the entry, it will need to build a new list with
> > the entry replaced at the same position.  That means it's O(n) to update
> > (for new keys it's O(1), they can just be consed onto the front).
> > In total, that's O(2n).  The major extra time you see can not be
> > explained due to that, but the output of time gives a clear hint.
> 
> Why was alist-update introduced, anyway?  It is more efficient
> to use either alist-update! or alist-cons (from SRFI 1) in any situation
> I can think of.  I note that neither SRFI 1 nor the alist-lib egg has it.

Simple: for those who prefer functional updates, but don't want their
lists to keep growing endlessly.  Also, in some cases duplciate entries
really mean something different (for example in alist->uri query attribute
mappings and such).  You could argue that means they're not true alists,
but it sometimes is convenient to treat them as such.

Cheers,
Peter
-- 
http://www.more-magic.net