This is a special post for quick takes by gwillen. Only they can create top-level comments. Comments here also appear on the Quick Takes page and All Posts page.
Here I use "option" in the sense of C++ std::optional<> / Rust Option / Haskell Maybe.
It feels to me like "real-world data" often ends up nested in thick layers of "optionality", with the number of layers limited mostly by how precisely we want to represent the state of our "un-knowledge" about it. When we get data from some source, which potentially got the data in turn from another source, and so on, there is some kind of fuzziness or uncertainty added at each step, which we may or may not need to represent.
I'm thinking about this because I'm feeding data from Home Assistant into Prometheus/Grafana to log and graph it, and ran across some weirdness in how HomeAssistant handles exporting datapoints from currently-unavailable devices.
Layers of optionality that seem to exist here:
I have obviously added every conceivable layer I could think of here, including some that don't usually get thought about in a uniform way, and some that we would in practice never bother to distinguish. But I'm a data packrat, and also an amateur type theorist, and so I think a lot about data representations.
This whole thing shades into another space I think a lot about, which is error handling in programming languages and systems.
Some parts of the stack I described above really seem to fall under "error handling" -- what do you do if you can't reach component A from component B? Others seem to fall under "data representation" -- If you poll someone who they're voting for, and they say "I'm not voting", or "I don't know", or "fuck you", or "je ne parle pas Anglais", what do you write down on the form (and which of those cases do you want to distinguish versus merge?) But the two are closely related.