3 ms·

I like the principle of "make unauthorized states unrepresentable", but it makes me nervous, or at least evokes a nuance that is well addressed by https://githu

I like the principle of "make unauthorized states unrepresentable", but it makes me nervous, or at least evokes a nuance that is well addressed by https://github.com/tree-sitter/tree-sitter https://github.com/tree-sitter/tree-sitter > Robust enough to provide useful results even in the presence of syntax errors Especially when it comes to human-generated input (but even outside of that) it is beneficial to have a representation for unauthorized states, so long as you can easily detect that that's what you're representing. That allows you to better report errors, or try to mitigate them. In other words, don't forget to have an https://wiki.c2.com/?EscapeHatch https://wiki.c2.com/?EscapeHatch

mumblemumble 6y ago
The dictum is usually phrased as, "make illegal states unrepresentable". Perhaps this is just playing with semantics, but, to me, that difference in wording is incredibly important. An unauthorized state (which I'm interpreting here to mean an error state) may not be on the happy path, but that doesn't necessarily mean it's invalid. For example, "the user is trying to open a file, but they don't have permission to read it" is a valid state. The resulting error condition is also valid, even if it's not somewhere they want to find themself. An illegal state is, in the context of this phrase, meant to be one that's nonsensical. Perhaps "invalid" would be a better word. Think negative array indexes in languages that only let you index from the front of the array, or objects that are only halfway initialized. Situations where, having entered such a state, the behavior of the program is now undefined. We should strive to make it physically impossible get the program into a state where its behavior is undefined.