guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]