[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: srfi-69@xxxxxxxxxxxxxxxxx
- Subject: SRFI-44 compatibility
- From: "Scott G. Miller" <sgmiller@xxxxxxxxx>
- Date: Mon, 25 Apr 2005 17:00:40 -0500
- 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=Or7CdY9TVh7i2JJ1dSmbHdr/w4sh7NN+dtSjbgxGl4sImIDBerGyrskXgcw+qYcWsm4u1TRBf79W4XbjyAvGBToLNoUo4p9xkAniR0fzIfhuu7VscBje5mEExcVLH6XYtW1LXsYxRp4gVCdvYjpEDIgBT+UlkFn8qYq4+tBr0ic=
- Reply-to: "Scott G. Miller" <sgmiller@xxxxxxxxx>
First, its definitely a good thing to see hashtables get SRFI
treatment. It would be a shame though if they weren't defined as
compatible with SRFI-44, whose purpose is to unify datastructures so
that they can be used generically and consistently in programs.
This basically only entails a little effort in procedure naming, and
in providing compatible fold functions. It would be nice to say also
that implementations that support SRFI-44 must support the hashtables
for the generic elements of SRFI-44.
This wouldn't prevent implementations from supporting only SRFI-69,
but it would make the code consistent and portable between a 69 only
and a 44/69 implementation without a duplication of effort and API.