Functional vectors for guile
renamed readme
c4834f91d0e7 — Linus Björnstam 1 year, 2 months ago
Added (ice-9 threads) to the used modules, since it was removed from (guile).
d0269ce64b88 — Linus Björnstam 1 year, 4 months ago
Fixed some stupid bugs,

heads

tip
browse log

clone

read-only
https://hg.sr.ht/~bjoli/guile-fector
read/write
ssh://hg@hg.sr.ht/~bjoli/guile-fector

#guile-fector - Persistent vectors for guile

This is a guile implementation of persistent vectors for guile. They are really nifty little data structures that do amortized O(1) pushes, and "effectively o(1)" (as in log32) set and get. To speed things up this little library provides a transient interface which updates the fectors in-place.

#Credit where it's due

This was written by Andy Wingo, and I got his permission to work with the codebase. I added some convenience procedures over fector-fold, and found two small bugs.

#Documentation

Currently there is no documentation since I can't make guild doc-snarf to extract my documentation comments, but if you look in the file fector.scm you will find that all exported procedures have a small description.

#Example

Just a short example demonstrating general gist of things:

(import (fector))
(define f (fector 1 2 3 4))
(fector-set f 0 5) ;; => [5 2 3 4]
f ;; => [1 2 3 4]
(define t (transient-fector f))
(fector-set! t 0 5)
(fector-push! t 5)
t ;; => [5 2 3 4 5]

#Speed

In my unscientific benchmarking fectors are faster than (ice-9 vlist) at everything except random access. Both building and iterating through fectors is about 2x faster, but random access is about 2x slower. This might be a little bit due to the dispatching code of fector-ref, but probably mostly due to that the vlist-ref is simply faster due to the data structure being simpler.

#License

Andy asked me to use the Blue Oak Model license 1.0, which is a permissive license with a patent grant. The license text is available in the LICENSE file and at this web address: https://blueoakcouncil.org/license/1.0.0