Re: Functional hashtables

[Linus Björnstam]

I made a module out of Andy's dash (and added some comfort functions over 
fash-fold): https://hg.sr.ht/~bjoli/guile-fash/browse/fash.scm?rev=default 

What it lacks is a proper way to remove elements..I had a couple of stabs at 
it, but I fear I was too dumb.

-- 
  Linus Björnstam

On Tue, 5 May 2020, at 20:10, Christopher Lemmer Webber wrote:
> Hello hello,
> 
> I'm working on porting a library I've written from Racket to Guile.
> Some interesting news on that soon.
> 
> In the meanwhile, I'm trying to figure out what to do about my need for
> functional hashmaps in Guile.  Right now Guile ships with vlist and
> vhash.  Andy also wrote fash.scm, which is what I've generally preferred
> and used previously.
> 
> The reason I don't want to use vhashes is specifically this part of
> vhashes in the Guile manual:
> 
> >   • It is _not_ thread-safe.  Although operations on vlists are all
> >     “referentially transparent” (i.e., purely functional), adding
> >     elements to a vlist with ‘vlist-cons’ mutates part of its internal
> >     structure, which makes it non-thread-safe.  This could be fixed,
> >     but it would slow down ‘vlist-cons’.
> 
> Oop!  That's a no-go for me.  But maybe there are other reasons to
> prefer fash.scm too?
> 
> There's no separate package of guile-fash available anywhere, but it
> would be easy enough to do if we're just using it with Guix.  It's
> desirable to not have to keep copy-pasta'ing fash.scm around at least.
> 
> My time in Racket has convinced me that it's an extremely good idea to
> have a well supported functional hashmap type in the language... extra
> points if it's "first class" in syntax (my code has improved
> considerably because of it; no more using alists where they'll bite you
> later just because it "looks prettier").
> 
> Anyway, thoughts?
> 
> Nice to be back in Guile land!
>  - Chris
> 
>