3 ms·

Fair enough, though I think a functional approach (you create a new set from the old, with one field changed), and somehow “committing” it back is fine, and no

by kaba0 3y ago

Fair enough, though I think a functional approach (you create a new set from the old, with one field changed), and somehow “committing” it back is fine, and no need for side effecting then (besides at the boundary). Maybe structural typing is somewhat similar to what you think of? Probably typescript, maybe go are the most well-known for this out of the statically typed ones, but clojure is also all about every “object” being a key-value map.

cmrdporcupine 3y ago
Yeah, a functional approach is fine. In reality you can think of an "update" to a tuple in a relation as a "replace this relation-valued variable with a new one where this tuple has been modified." And so mutations to base relations ("tables" in SQL parlance) just means changing the value of that relation in in the global shared, named base relation list. And if you use a persistent data structure behind the scene, and do CoW etc, you can even probably make this relatively efficient... And I don't think it's so much structural typing, as it is defining method/function dispatch off predicate matches. More.. structural values? Clumsily: Disconnect(connection_id) = with project ConnectionState CS where CS.Id = connection_id { if CS.state != 'connected Raise('not_connected) else CS.state = 'disconnected }
- senderista 3y ago
  Mutating a tuple in a relation doesn't really make sense per se, because a relation is just a subset of the cartesian product of its attribute domains, and only value-based semantics apply to sets. What does make sense is identifying a primary key for a relation, deleting a tuple, and inserting another tuple with the same primary key but different values of its other attributes. In practice, of course, this is equivalent to in-place mutation of identity-objects corresponding to unique values of the primary key.

by kaba0 3y ago

cmrdporcupine 3y ago

Yeah, a functional approach is fine. In reality you can think of an "update" to a tuple in a relation as a "replace this relation-valued variable with a new one where this tuple has been modified." And so mutations to base relations ("tables" in SQL parlance) just means changing the value of that relation in in the global shared, named base relation list. And if you use a persistent data structure behind the scene, and do CoW etc, you can even probably make this relatively efficient... And I don't think it's so much structural typing, as it is defining method/function dispatch off predicate matches. More.. structural values? Clumsily: Disconnect(connection_id) = with project ConnectionState CS where CS.Id = connection_id { if CS.state != 'connected Raise('not_connected) else CS.state = 'disconnected }

senderista 3y ago
Mutating a tuple in a relation doesn't really make sense per se, because a relation is just a subset of the cartesian product of its attribute domains, and only value-based semantics apply to sets. What does make sense is identifying a primary key for a relation, deleting a tuple, and inserting another tuple with the same primary key but different values of its other attributes. In practice, of course, this is equivalent to in-place mutation of identity-objects corresponding to unique values of the primary key.