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

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 }