Identity doesn't imply 'value' equality, that's the whole point of mutability! Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.
My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number).
Objects refer to other objects using their (immutable) identity. In turn, resolving identities to objects requires (version) scope which can be in the past or present.
CodeQL is another datalog with the domain of code analysis as its use case. Too bad you cannot create a custom fact database with CodeQL. Otherwise, the implementation of CodeQL is pretty advanced and efficient.
Okasaki got me interested in confluently persistent data-structures, way back in the 2000s.
They seem magical! To be able to combine data from the past with current data, efficiently!
They are almost always trees, with the exception of skip-lists, with all operations O(log(n)), .
After creating my own programming language Enchilada that is based on immutable data structures, I started considering what I deemed "next level":
Uniquely represented confluently persistent data structures
Combined with a Merkle tree encoding of such uniquely represented data structures (they are almost always trees), you can efficiently and incrementally authenticate them. Think 'block chain' on steroids, with incremental cryptographic hashes. Or torrents, if you are into that kind of thing.
As always it is the journey that matters (writing), not the outcome (the essay).
For example, students could record their writing of an essay with a keylogger or something.
Additionally - with the use of some advanced zero-knowledge algos or crypto timestamp provenance - it should be possible to prove that they have written the essay, without revealing their recording.
SeqHashes are uniquely represented Merkle Trees that also represents a sequence. Concatenation of two SeqHashes is O(log(n)). In turn, the cryptographic signing of SeqHashes is O(1) as each tree node carries a cryptographic hash.
Of course, for each node to carry a hash incurs a hefty overhead but that can be alleviated by (lazily) grouping nodes into buckets (turning it in some kind of BTree).
SeqHashes also don't support splitting in O(log(n)) like for example AVL trees.
I've created an Btree version of SeqHash that also allows splitting SeqHashes in O(log(n)) called SplitHash.
I also personally think CUE hits a sweet spot. The union (pun intended) between types and values (both sets) is really a game changer!
CUE is indeed not trivial to implement, especially its intricate semantics are tricky. I work an a CUE alternative, called ReSeT to really understand the semantics better.
Visual is all nice and all, but I really fancy the 'computational' model of spreadsheets which is very easy to learn and apply IMO.
My latest find is the CUE language, which I believe is the first 'typed' version of a spreadsheet (in disguise). CUE is like spreadsheets, but on steroids!
Yes I concur: CTEs is closer to the spirit of relational algebra: every step/expression should yield a table/relation.
As data munging is about combining/correlating/sorting/grouping data, why not have a sound (bag) algebra to do that? Such algebra would give us equational reasoning, proofs, etc.
And consequently: students would be learning an algebra which is easier to learn IMO.
My first encounter with 'SQL' was a course on relational algebra that was taught at my university.
It started out with defining relations as a mathematical construct, and continued with various operators on such relations. Then they continued explaining the various normal forms up the fifth normal form.
I was completely out of my depth, but at least it was good and solid theory that could be learned.
What really messed with my head is they then introduced SQL as a 'practical' implementation of relational algebra.
I'm still having nightmares where I try to understand nested HAVING statements that where asked at the exams.
Hey relations don't contain duplicates! But that's OK. We should call (modern) SQL 'BAG ALGEBRA'.
hey, I like your work on Paranoid Scientist. I've never come across hyper-properties: is this something you invented?
Regarding hyper-properties: I assume they only work on immutable data values, otherwise it would be hard to manage historical objects so that they can be part of any of the predicates.
I'm working on a similar project that you may find interesting: https://odipar.github.io/manikin/. I may want to include hyper-properties in future releases.
I think immutability (or immutable state) adds one big advantage over mutable state: you have access to previous state(s) and the current state.
Immutability is very convenient for checking post-conditions that compare previous states and the current state for certain properties that should hold (temporal properties for example).
In turn, post-conditions guard your states to be sane.