I agree. Also, if there is no strong reason to deviate from RnRS, that
would be a good choice. (But, I'm also no maintainer.)
On Wed, Feb 23, 2022 at 8:42 AM Linus Björnstam <
linus.bjorns...@veryfast.biz> wrote:
> Hej!
>
> I would also propose a hash table based on a more sane interface. The
> e
yep that's a working solution, currently I make a proper goops class and
the methods will dispatch to the right version.
On Wed, Feb 23, 2022 at 8:41 AM Linus Björnstam <
linus.bjorns...@veryfast.biz> wrote:
> Hej!
>
> I would also propose a hash table based on a more sane interface. The
> equali
Hej!
I would also propose a hash table based on a more sane interface. The equality
and hash procedures should be associated with the hash table at creation rather
than every time the hash table is used. Like in R6RS, srfi-69, or srfi-12X
(intermediate hash tables).
Maybe the current HT could
(Note that the resizing means *rehashing* of all elements.)
On Mon, Feb 21, 2022 at 11:17 PM Mikael Djurfeldt
wrote:
> The hash table in Guile is rather standard (at least according to what was
> standard in the old ages :). (I *have* some vague memory that I might have
> implemented a simpler/f
The hash table in Guile is rather standard (at least according to what was
standard in the old ages :). (I *have* some vague memory that I might have
implemented a simpler/faster table at some point, but that is not in the
code base now.)
The structure is a vector of alists. It's of course importa
A datastructure I fancy is hash tables. But I found out that hashtables in
guile are really slow, How? First of all we make a hash table
(define h (make-hash-table))
Then add values
(for-each (lambda (i) (hash-set! h i i)) (iota 2000))
Then the following operation cost say 5s
(hash-fold (lam
