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.
> 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).
Are you storing the version as part of the object? If so, they’re no longer equal values regardless of identity. If not, what purpose is there in versioning the same value? Even if there is a purpose, are same-value-different-version objects not otherwise interchangeable unless/until some value change does occur?
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.
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.
Yes, sort of, though if the economic incentive was high enough, someone could connect the AI to input through the keyboard and "type" out the essay. At scale it would be cheap. You could record video of you typing, which would work for some time until at some point video fakes get advanced enough... sigh.
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!
