Modern Common Lisp with FSet(fset.common-lisp.dev) |
Modern Common Lisp with FSet(fset.common-lisp.dev) |
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?
When I'm reading in an Info reader (almost always in GNU Emacs) I always hit the spacebar when reading. This scrolls down a page and, if it's at the end of a page and, if at the bottom, goes to the next subnode - in other words, what "makes sense." (Actually the binding for this is "Info-scroll-up".)
That doesn't help when you're on a website, but for me Texinfo websites have a distinctive look and when I see them, I immediately know what clicking "Next" will do, and I know to instead go to the bottom of the page and go to the subnodes if that's what I want, which it typically is.
I agree that it's weird...but maybe understanding the overall weirdness of Texinfo helps it all make sense?? A more coherent weirdness?
The relation of 1.1.1 to 1.1 is about drilling down into detail if you want that, where you can still peruse through at the given upper level.
Picking another random other manual, it is the same: https://www.gnu.org/software/guile/manual/html_node/index.ht...
For instance, each CHAMP node is a single CL vector; the header occupies the first few slots rather than being a separate allocated ooject.
2. There are no mutations
3. I think it would be rather redundant to mention that every operation that returns a new object conses.
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.
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.
[1] https://old.reddit.com/r/Common_Lisp/comments/1sk2nsl/fset_v...
The documentation [1] seems to be in texinfo format that's commonly used for making info files used distributed with GNU and Emacs. It is converted into multipage HTML using two commands in the Makefile. You could modify them trivially to build what you want. I use it along with Sigil (epub editor) to build EPubs of user manuals for my EReader.
[1] https://gitlab.common-lisp.net/fset/fset/-/tree/master/Doc/M...
Here's the diff. Claude helped me track down the link -> ref problem. https://github.com/shawwn/fset/commit/ce42cffde11fb84c075ddb...
Surprisingly it took 10 minutes total. Surge seems nice. (npm i -g surge)
> 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.
As far as constant factors go, this library is a middle ground; they strive for low constant factors in their algorithms, but it relies almost entirely on generic functions, so that alone is going to limit the maximum speed in e.g. tight loops.
That being said, for batch processing in single-threaded applications, the older SBCL gc is actually pretty good.