Key points include:

- 100% immutable datastructures

- Immutability is leveraged to make a lot of core operations concurrent

- Continuation-based threading model and Actor-based concurrency

- Fun little VM implemented behind the scenes

That being said, the documentation strongly contradicts the title!

> The goal has not at any point been to become an ultimate Lisp and take over the world

▲

ValentinA23 10 months ago | parent | next [-]

I'm wondering if a language could optimize immutable data structures to use mutable, in place semantics instead of duplication or structural sharing when it is possible. When an immutable data structure only has one consumer (only has one descendant in the flow graph), then it can easily be turned into a mutable version. Generalizing, any linear subgraph in the program's flow graph could be made to use in place semantics on the same mutable variable.

The challenge I guess is figuring out how variables captures by lambdas should be dealt with.

▲

masijo 10 months ago | parent | next [-]

This is how Clojure does it, take a look at this: https://clojure.org/reference/transients

It's great, one of the many awesome features Clojure has.

▲

zellyn 10 months ago | parent | prev | next [-]

This is the bet Roc is taking. They call it "Opportunistic Mutation" and you can read about it at https://www.roc-lang.org/functional

I didn't see links on that page, but IIRC, there's a particular paper they reference as the main idea.

	▲	ketralnis 10 months ago \| parent [-]
		Python also detects this situation (at runtime using refcounts) and does in-place mutations where possible https://github.com/python/cpython/blob/a2ee89968299fc4f0da4b...

▲

zvrba 10 months ago | parent | prev | next [-]

I implemented an academic paper (join tree) in C# here https://github.com/zvrba/Pfm

It provides the opposite: a mutable CoW data structure that is extremely cheap to "fork" so that all subsequent updates occur only on the new "fork" and are invisible to the old "fork".

▲

zelphirkalt 10 months ago | parent [-]

Isn't that the point of well designed persistent data structures?

	▲	zvrba 10 months ago \| parent [-]
		Depends on how you define "persistent data structure". In most definitions that I've encountered, a new version is made after each update. This code makes a new version only when you explicitly request it with Fork(). This allows you to - Use the data structure as a "standard" tree, sharing one instance across threads and use locking for thread-safety - Use it as a fully-persistent structure by calling "Fork" before every modification - Or anything in between I needed the 3rd case: a cache manager gives out a forked view of the actual cache contents to its clients. Thus the cache is always in control of the "master" copy, and if a client modifies its own fork, the cache and other clients are not affected.

▲

coldtea 10 months ago | parent | prev [-]

>I'm wondering if a language could optimize immutable data structures to use mutable, in place semantics instead of duplication or structural sharing when it is possible.

Yes, many languages (and libs, e.g. for JS) do that.

▲

dleink 10 months ago | parent | prev | next [-]

> The goal has not at any point been to become an ultimate Lisp and take over the world

obviously something a lisp that had designated itself ultimate and was keen to take over the world would say.

▲

zelphirkalt 10 months ago | parent | prev [-]

Does it feature implementations of lots of purely functional data structures then? Or does it only apply to a few builtins?

And would other Schemes be free to copy those?