[brundolf]

The key is to use reference-counters. If you think about it, no lisp is really going to fit the single-ownership model. Many of them are implemented on GC'd languages for this reason. Rc<> is the standard Rust answer for GC, and in practice means you don't really have to deal with ownership issues for those values.

I implemented my own Rust lisp if you want an example: https://github.com/brundonsmith/rust_lisp

And here's a more general resource (not written by me) on this class of problems and the surrounding subject matter: https://rust-unofficial.github.io/too-many-lists/

[hhas01]

How does Rust reference counting handle cycles? Python is famously reference counted, and even it ended up having to strap on an occasional GC cycle to mop up after those. Or do you just accept that if it leaks, it leaks? Which for most finite-lived programs on generous modern hardware may be a sufficiently acceptable solution.

...

Still, I do idly† wonder if there could be better schemes[sic] than just slavishly refcounting everything? e.g. If you know which values never escape a given scope, maybe just dump them into a single-ownership pool that’s collected whenever execution finally leaves that scope. Which, for lists that compose the program itself, is the entire lifetime of the program (so no need to explicitly collect assuming the OS is happy to clean up after the program exits). It’s really just values that leave their originating scope that need to start refcounting (although, of course, there’s a raft of ways they can sneak out of that).

Although I think the most inventive answer to dynamic memory management was the language that simply tossed all newly created values into a single global cache, from which it periodically swept all values that weren’t touched again within a fixed period of time. (Obviously requiring 100% referential transparency, so that if an already-flushed value is needed again, it can simply be regenerated from scratch.) Alas, I can’t remember that language’s name (I think it’s an older and obscure one), but simple, effective, and sneaky AF? #MeLikes

--

† Alas, while I have considered implementing a scripting language in Rust (to teach myself Rust as much as anything else), I’m already painfully slow writing them in HLLs that do all that low-level stuff for me. #BoVLB :/

[steveklabnik]

Rust-the-language doesn’t know anything about multiple ownership.

The standard library refcounted types don’t do anything special, if you get a cycle you leak. You can use weak refcounts to try and prevent this.