[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Functional datatypes in Guile
From: |
pukkamustard |
Subject: |
Re: Functional datatypes in Guile |
Date: |
Sat, 04 Mar 2023 16:38:48 +0000 |
Hi Dave,
"Thompson, David" <dthompson2@worcester.edu> writes:
[..]
> Your Guile port of (srfi srfi-146 hash) looks really nice! A
> functional hash is the most important data structure for our needs at
> Spritely. Do you know if it's thread-safe (unlike vhashes)? Andy's
> fash implementation uses atomic boxes, for example.
I know very little about thread-safety, but the implementation is purely
functional, and thus should be thread-safe. By purely functional, I mean
that no state is mutated. Calls that update mapping return a new
mapping. The old mapping remains unchanged. I imagine that if multiple
threads want to access (and modify) the same mapping they would have to
agree on the current mapping by keeping a reference to the current
mapping in an atomic or similar.
Makes me wonder, are Andy Wingo's fash/fector purely functional? Why do
they need atomic boxes? Aren't they only necessary for destructive
updates?
> Also, what are your thoughts on read syntax? I find myself using
> alists more often than I probably should because the syntax is
> pleasant. (hashmap comparator 'foo 1 'bar 2) is... okay, but terse
> syntax for the common case of a hash with literal keys would be nice.
> For example, #hq((foo 1) (bar 2)) for a hash with keys compared with
> eq? Scheme is kind of odd for not having hash literal syntax.
No strong opinions on a read syntax. But I welcome anything that might
increase adoption of purely functional data structures. I think they're
cool! :)
- pukkamustard
- Re: Functional datatypes in Guile,
pukkamustard <=