Alexis King

I've been calling this the "golden rule of engineering": to propagate requirements upstream instead of propagating failures downstream

Going to use this in the compilers class! It communicates an important aspect of the design we’re trying to teach.

There's a related idea in dependent types: don't compute a Boolean, compute a Decidable, which includes the proof for the yes/no decision, whichever way it goes.

To go one step further, the "right way" to specify a non-free data structure (few data structures are free) is through a pair of parser and unparser... from and to SEXP, not flat character streams, so I can non-trivially interact with it at my Scheme REPL.

And the parser/unparser should be specified together as a schema built out of partial isomorphisms, which allow you to only duplicate parser and unparser at the primitive level, and then use partial isomorphism composition operations to build schemas for more complex structures.

> All in all, the second approach is superior on all axes. That doesn't seem right. There is a trade-off here: none of our existing List functions will work on NonEmpty.

I suspect it's only b/c of heavy use of typeclasses in Haskell that this is bearable in practice. eg. if your code depends on Traversable instead of List, all you need is a new instance, which is much more bearable than rewriting a bunch of list-processing code.