Hidden 13 paragraphs down the third page is the first actual description of the project:
> So FSet has a dual mission: first, to bring Common Lisp up to date, by giving it a much richer ensemble of functional collection data structures, to greatly expand the space of algorithms that can be written in an elegant functional style and still run efficiently; and second, as with Clojure, to support and encourage the use of functional collections for general programming.
Cool project but the docs could be greatly improved by putting the purpose of the project front and center. Don't make readers guess.
Strings are immutable [in Scheme]. Functional point update operations are not provided, presumably out of time complexity concerns, but string-append and substring are provided, and there are functions to convert to and from lists of characters; I guess the idea is that fine-grained string construction will be done using lists and then converted. Amusingly, there’s string-copy, though it’s hard to see why one would ever use it.
Strings are actually mutable in R6RS. See https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_s... - there is an imperative update-in-place function which mutates the argument. So of course string-copy really is useful, you might want to mutate a string and keep an unaltered copy. And the intent of string->list is to automatically let your list-processing code become string-processing code. It is way too strong to say "Functional point update operations are not provided, presumably out of time complexity concerns" - R6RS actively encourages functional operations on strings by calling string->list first, even though that's O(n) overhead.
The overall point you are making seems clearly correct: R6RS Scheme does not provide any "mostly functional" datatypes beyond basic s-expressions, so it would take a lot of work to develop Clojure/FSet-style tools. But it's strange to so badly misstate what strings in Scheme are like.
Why is it too strong to say that functional point update operations on strings are not provided, when you seem to confirm that the supported way to manipulate strings functionally is to convert them to lists first?
Persistent/functional data-structures aside, bags are the most useful data type that is omitted from many container-libraries (whether or not the containers are part of the language stdlib).
Balancing trade-off is crucial in software design. It would be nice if the documentation listed the trade-offs of the structures compared to their native implementations. I imagine at least every mutation is consing? There are also larger fixed and slow-growing overheads in various operations.
I think the website is weird to navigate. "Next" links go to top-level headers instead of the "logical" next. For example, if I'm on "1.1 Fset Tutorial" clicking "Next" takes me to "1.2 Using Fset" instead of "1.1.1 The Major FSet Types".
At a conceptual level, do these data-structures store what in other languages would be pointers and so every access would mean paying for the pointer indirection or do they store objects themselves and they are cache friendly data-structures?
14 comments
[ 3.8 ms ] story [ 45.8 ms ] thread> So FSet has a dual mission: first, to bring Common Lisp up to date, by giving it a much richer ensemble of functional collection data structures, to greatly expand the space of algorithms that can be written in an elegant functional style and still run efficiently; and second, as with Clojure, to support and encourage the use of functional collections for general programming.
Cool project but the docs could be greatly improved by putting the purpose of the project front and center. Don't make readers guess.
Good suggestion, thanks.
[0] https://github.com/ruricolist/cloture
The overall point you are making seems clearly correct: R6RS Scheme does not provide any "mostly functional" datatypes beyond basic s-expressions, so it would take a lot of work to develop Clojure/FSet-style tools. But it's strange to so badly misstate what strings in Scheme are like.
At a conceptual level, do these data-structures store what in other languages would be pointers and so every access would mean paying for the pointer indirection or do they store objects themselves and they are cache friendly data-structures?