This library serves as the basis of cloture[0] an effort to host Clojure on Common Lisp. I hope to see both projects thrive!<p>[0] <a href="https://github.com/ruricolist/cloture" rel="nofollow">https://github.com/ruricolist/cloture</a>
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.
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).
I remember watching you give a version of this talk at the Bay Area Lisp meetup!
Nice thanks, is there a single-HTML-page view available by any chance?
Just FYI, this section at the end about R6RS Scheme is a little confused: <a href="https://fset.common-lisp.dev/Modern-CL/Top_html/Scheme-_0028R6RS_0029.html" rel="nofollow">https://fset.common-lisp.dev/Modern-CL/Top_html/Scheme-_0028...</a><p><pre><code> 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.
</code></pre>
Strings are actually <i>mutable</i> in R6RS. See <a href="https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.12" rel="nofollow">https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_s...</a> - 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.<p>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.
Hidden 13 paragraphs down the third page is the first actual description of the project:<p>> 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.<p>Cool project but the docs could be greatly improved by putting the purpose of the project front and center. Don't make readers guess.
Okay, I buried the lede :-)<p>Good suggestion, thanks.
If you see this — have another look — I think I've improved it.
Not OP but it looks great! Your humility is much appreciated. I am excited for the Lisp community, and will follow this approach to CL as I do with Jank's approach to Clojure.
I didn’t see the old one, but the current page made it clear straight away!
I don’t know how it was before, but I found this immediately.
[dead]