[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: srfi-69@xxxxxxxxxxxxxxxxx
- Subject: Re: Naming
- From: Alex Shinn <alexshinn@xxxxxxxxx>
- Date: Wed, 27 Apr 2005 11:34:32 +0900
- Delivered-to: srfi-69@xxxxxxxxxxxxxxxxx
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=C5UCokoeovxi/QqJUE1SvQ8FXQwKwUy+5PtLz28qJuD37tLC+FHpv63rOns2mHBaJXFZhKa69P62AWpgjhDvGmTw1H/lEmylfnWMECvA0OIa1spZnLQ4eGjPO05cPkQ2CLD0HWnZTNgR2KY5ZUi/lR7JCXJEYpFKtJ6wdCN8cTA=
- Reply-to: Alex Shinn <alexshinn@xxxxxxxxx>
Marc Feeley wrote:
> Semantically your hash tables are fundamentally a structure associating
> keys with values. This can be implemented with hash tables, search
> trees, association lists, and many other ways.
Semantically they are hash tables, and the interface is inherently tied to
the hash function.
A higher-level table object which only used a hash function and/or less-than
comparator as optimization hints would be possible, but that doesn't seem
to be what this SRFI is aiming for.