Clojure’s Approach to Identity and State (2008)
clojure.org
clojure.org
But there have been very important developments in programming languages since this post/page was written: notably, the introduction of "borrow checking" (exemplified by Rust's implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that "imperative programming is founded on an unsustainable premise" feel dated.
It is worth taking the time to understand what borrow checking enables. For example: borrow checking allows even mutable datastructures to be treated as values with structural equality. It does this by guaranteeing that unless you have exclusive access to something, it may not be mutated.
A good explanation of the benefits of ownership and borrow checking: http://squidarth.com/rc/rust/2018/05/31/rust-borrowing-and-o...
You can avoid this complexity by killing either one of the adjectives: shared OR mutable. Immutability is generally pitched as the only way to solve this problem, and it is definitely a valid solution, though not the only one. The other dimension to cut off is sharing. If mutable data is not shared, its mutability also becomes mostly irrelevant.
Rust and Swift both support immutability as well as unshareable references. In Rust’s case, it’s more like organized sharing that prevents simultaneous mutation. In Swift’s case, structs truly can only have one reference.
One does not replace the other, they coexist solving different problems.
When immutable values (whether it's the number 5 or a record, or whatever) are used with a pure function then the returned value can be essentially a direct replacement for the function invocation, making the operation essentially take zero time (i.e. there aren't intermediate mutation states, locks, or any other coordination).
This is the point that Rich Hickey suggests in a number of his talks [1] - which are always excellent IMHO.
[1] Are We There Yet - https://www.youtube.com/watch?v=E4RarTAZ2AY
The same can be said of any variable in Rust that is passed to a function via immutable reference. Borrow checking guarantees (at compile time, with no runtime overhead) that even if a user passes something that supports mutation (such as a BTree or an array) to a function, that that function may not mutate unless it has permission to.
This means that if you have an immutable reference to something, it can be treated as a value. For example: a Vec or BTreeMap (structures that supports mutation) can safely and easily be used as Map keys in Rust, because borrow checking guarantees that once the Map has taken ownership of the structure, it "is a value": ie, is immutable.
I don't think this is correct. Rust does not really have immutable references, it has shared references vs. exclusive ones. Shared references are ordinarily immutable, but controlled mutability can be reintroduced (directly or indirectly) via a variety of type constructors (Cell<>, RefCell<>, Mutex<> etc.). Hence something that is borrowed immutably cannot be assumed not to change in the general case-- unless one also takes care to work with these mutability mechanisms as needed, which cannot really be done in a "fully general" way. Rust developers seem to have realized that actual immutability is not that easy, and that the guarantees that they do offer may be more appropriate.
Clojure also recognizes the connection between ownership and mutability in its "transients": https://clojure.org/reference/transients ... compile time borrow checking extends that idea to an entire language.
But in Clojure it's not a problem. I find lots of applications where working with stale, consistent data is just fine.
Also, if you ever need to rewind your state Clojure's immutability makes it trivial. I've used this in e.g. latency compensation for multiplayer games.
The way you are forced to model things so that the borrow checker can successfully validate your code can often be frustrating, and it also comes at the cost of slow compile times and interactive programming, which Clojure is kind of a champion at, so I'm not sure it would be a good fit to add a borrow checker to it.
I love the borrow checker for manually managed memory though, and for programs that need that kind of performance and tight memory usage, it is great. I've been following along the development of Carp because of that and my preference of Lisps: https://github.com/carp-lang/Carp
Then, do not mark your variables as mutable. This error only happens if you use `let mut variable_name = ...`
AFAIK, `let var`, e.g. immutable variables, behaves the same as in clojure.
default behavior should be safe and simple to use, dangerous behavior should be hard to reach and inconvenient to use.
I understand your point, but to me that is exactly the case. It requires the extra "mut" (harder to reach) and is inconvenient to use (more compiler errors).
My point is; Rust gives you the choice. If you need mutability due to performance, or something like that, you can have it (at the cost of simplicity and convenience).
Also, "dangerous behavior" is not allowed, in this example threads sharing mutable and immutable reference to the same object.
top comment claim is that clojure's approach to identity and value-semantics is somehow superseded and invalidated by rust's ownership and borrow checker, which is just too much koolaid. example i gave illustrates that given rust's default tools somebody will either have to deal with unnecessary low level errors (has nothing to do with high-level business logic of "i need this array to have new data") or will find a way to write incorrect code. none of that will happen given clojure's default tools.
I have this little lightly-tested library: https://github.com/tne-lab/rw-synchronizer. I'm not using it much currently but have played with it a lot while building extensions to Open Ephys. The idea being that as a reader, you get a "snapshot" of the last thing that was written, but it's really just one of several copies, and subsequent writes can happen on the other copies. So you never really modify the current data, just push newer versions of it. The cool thing is, if you know how many simultaneous readers you'll need ahead of time, all the allocation can be done upfront, so then if you have a real-time loop or something, all it needs to do is exchange pointers.
If I ever get around to it, the next thing I would do is allow any writer to also read the latest value, so it can use a transformation to create a new one. Maybe even do it automatically with copy-on-write semantics? On the other hand, I'm probably reinventing the wheel here...
I was focused on situations with just one writer (and originally also one reader), with the main thing being avoiding allocations. The situation where future values actually depend on past values, and specifically the current past value with other writers in the mix, is definitely trickier.
I want to learn Clojure, but there are definitely some road blocks. I don't have the time for Emacs, it'd be a pain to get a Cursive license (although the cost is extremely reasonable I'd have to do paperwork at work), and I don't know the JVM or Java well.
With ClojureScript you can leverage JavaScript runtimes like browsers.
The ClojureScript testsuite also passes using the recently released hermes runtime (https://twitter.com/mfikes/status/1149360258994847745)
edit: Just wanted to add that being familiar with Java or the JVM isn't necessary to get into Clojure. It definitely is not a prerequisite :)
I like the idea of Clojurescript, but don't currently have any reason to do web development.
It's a simple Clojure IDE written in Clojure.
In Software Transactional Memory, that can be accomplished with atomic swaps. In Clojure, a new value, no matter how large, is constructed and the transaction is completed by repointing a mutable reference (ref or atom) to the new value atomically. Clojure has plenty of tools for constructing such transactions, such as `update-in` [1].
In order to make this work well, we need to be able to make collections behave like values. So, when you associate a value to a key in a Clojure collection, the original collection is unmodified and a new version is returned. This plays well into updating collections with STM - you just swap the root reference to a new collection.
Any transactions must be indempotent, that is, not touch the program state in any way, just produce a new value - because the STM system might need to retry the transaction. Retries happen when multiple threads try to modify a bit of shared state. In Clojure, `swap!` [2] is the actual mutation bit. You provide the transaction function to `swap!`, which produces a new value from the current state of a mutable reference. If, during the computation, another thread has swapped in a new value, the transaction is retried based on that updated value. On some architectures, this system can be implemented without locks, using the atomic compare-swaps of the hardware. The happy path of no conflicts is very efficient, while a heavily contested updates will result in redundant discarded (due to retry) transactions.
Please let me know if I can better explain anything!
Beyond that, you can actually just read the Clojure runtime code. It's a bit messy but there's not really that much there.
I have an efficient C# implementation here [2]
[1] https://michael.steindorfer.name/publications/phd-thesis-eff...
[2] https://github.com/louthy/language-ext/blob/master/LanguageE...
> Compressed Hash Array Map Trie
Q: “What datastructure would you like?”
A: “Yes.”
We are working with LibreOffice Calc ODS sheets, which are pretty terrible as a format (since the references are not normalized in the formulas, they can't repeat them even when they behave identically, and they duplicate most of the XML namespaces in the attributes).
We parse and normalize the references from A1 to R1C1 form, and then deduplicate the formulas (by text) and extract all of the immediates (and mark some of them as input, so that they can be varied at runtime).
Then we pass the deduplicated formulas through instaparse (which is spectacular) with a relatively simple grammar, and propagate some of the constants.
I then extract the references from the AST, while at the same time replacing SUMIF/MINIFS/MAXIFS/AVERAGEIF and similar with simple addition/min/max of known cells, where the tests are known at compile time. Then those ASTs are complied to functions (ignoring our cross-function optimizations).
Then it's just down to generating a complete DAG of dependencies, and using that to sort the assignments (cells) topologically. The sheet can be evaluated naiively at that point by injecting the references into each subsequent assignment/cell and storing the result in a map (ranges injected as a seq over a range).
There's a lot more to it, and it's getting better all the time, but that's the gist of it. Many real spreadsheets are not well-behaved, and they have dependency patterns which are more difficult to handle (i.e. ranges that refer to the current cell, or future cells, dynamically). The compiled output is getting more and more static, and will probably be reduced to some form of ssa, possibly even well-formed enough to be popped casually into LLVM.
It would be some help if the ODS format were improved, it takes several seconds just to parse the hundreds of megabytes of XML in our amazing spreadsheet, and a lot of it is redundant.
The common pattern in spreadsheets is to have a set of columns of repeated formulas. i.e.
| A | B | C | D |
|-----|-----|----------------|-----|
1 | | | | 0.12|
2 | 42| 42| =A2*B2+C1*$D$1 | |
3 | 69| 69| =A3*B3+C2*$D$1 | |
Whereas, with R1C1-type references.
| 1 | 2 | 3 | 4 |
|-----|-----|----------------------------|-----|
1 | | | | 0.12|
2 | 42| 42| =RC[-2]*RC[-1]+R[-1]C*R1C4 | |
3 | 69| 69| =RC[-2]*RC[-1]+R[-1]C*R1C4 | |
This makes it a lot cheaper to deduplicate them, because we don't need to run the whole parser on the 400k+ formula invocations in our sheet, and then compare the ASTs rather than text; since in this form, there are only a few thousand unique expressions rather than a few hundred thousand.
It's really for the best that they don't. ODS is XML, so they'd probably make the AST XML as well, which would outrageously oversized.
I prefer a programming language that allows me to pick and choose which paradigms I want to follow-- whether OOP or FP, mutable or immutable, etc. I don't need Clojure to do that for me.
Personally, I am trying to figure out why a closed source language is producing such activism-- trying to increase the popularity importance of the language... despite the fact that it's a privately owned language-- not really "open source"-- everything flows through one man & his company, which come first & above, regarding the language's development.
Rich Hickey: [Paraphrasing] "Open source isn't about you. I created this, it's mine, and I'll change it when and how I choose."
Clojure Community: "Hey, let's try to get more people into Clojure! Let's increase this community!"
Rich has a fairly strict development approach and wants to personally review and approve all changes to the core. There are complaints about that process, and that's fair. But as far as I have seen, most large, successful projects have similar personalities leading them (Stallman, Linus, Larry Wall, Guido...).
Finally, I should add -- if what you are looking for is software freedom... then you should absolutely consider using a Lisp like clojure. Lisp's give you the power to control your language through macros and non-core libraries. Unlike other languages, you do not need a core development team to make language changes for you. Perhaps this is why clojure is so powerful... because the core process issues you have heard about are not actually that important, and in fact the language itself enables substantially more software freedom than perhaps you are giving it credit for.