This example has nothing to do with type systems. The same system exists e.g. for Clojure (see Specter). The fundamental idea behind the approach in the articl

This example has nothing to do with type systems. The same system exists e.g. for Clojure (see Specter). The fundamental idea behind the approach in the article is the following: Treat the path through a nested data structure as a first-class thing. This gives helps us mainly in two scenarios: 1. Allowing for easy field-update-like code to exist for immutable data structures in addition to mutable data structures. This is especially valuable for updates. 2. Unify everything that can be "field-like" under a consistent field syntax. In most class-based languages we can write something like myObject.field0.subfield1.subsubfield2 but `field0.subfield1.subsubfield2` isn't a first-class item that we can pass around and use. We can certainly write something like the following: def myPath(someObject): return someObject.field0.subfield1.subsubfield2 but (to the first point) if someObject is deeply immutable, we can't use `myPath` to actually update `subsubfield2` and instead have to cumbersomely write out the entire reconstruction of an immutable data structure at every level. To the second point, even if someObjet were mutable, there are a variety of things that would be nice to have as field accesses, but aren't, simply because they don't fit into a class definition. As an example, consider the bits of an integer. # Imagine .permissions.bitMask.lastBit to be a path # through user set(user, .permissions.bitMask.lastBit, 0) is so much nicer than the corresponding bit shifting code. If path access through data were a first-class concept, there's no reason that paths should be restricted to only fields in classes. You can fit the same interface to anything that supports the notion of "field-like" access.