|
From: | Sjoerd van Leent Privé |
Subject: | Re: Immutable rnrs hashtable |
Date: | Mon, 26 Nov 2012 10:44:41 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 |
Hi Ian,The implementation is okay, I wrote a half baked example, as I understood the bit to be the mutable field. But it should act in reverse. Got it. In many cases, I use info-lookup-symbol in Guile's documentation, as it is much easier to navigate than the RNRS website (which I consider bad design, as there is no sensible hierarchy whatsoever or something of a decent index).
This is why I got it wrong, as the documentation was mistaken, and I did the opposite of what I should be doing. And yes, I was using #t and #f, But I expected the results to be the other way around.
Btw, isn't their a hashtable which is more pure in it's implementation? The RNRS and SRFI-69 versions are having quite some side-effects. I would have expected a method like "hashtable-add" which copies an existing hashtable, adds values and returns a new hashtable. I know, I prefer pure functional implementations...
Sjoerd On 11/26/2012 02:25 AM, Ian Price wrote:
Whoops, in my haste, I forgot to note that this _is_ a bug in guile's documentation, not in the implementation. Suggested fix included. Ludovic, Andy: Should I add him to THANKS too?
[Prev in Thread] | Current Thread | [Next in Thread] |