Making impossible states impossible

https://www.youtube.com/watch?v=IcgmSRJHu_8

On modelling in Elm. It teaches a few patterns for making your model more useful by:

1. Making impossible states impossible
   1. Two lists, or one list with two fields?
   2. Two maybes, or a union type?
   3. A non-empty list field alongside a selected field (where selected should be from the list), or a {start: List Item, current: Item end: List Item})
2. Designing an Elm API to hide implementation details (getter functions on private state)

Thinking about these patterns does make me really miss type classes and deriving, though. It would be super nice to be able to think about your questions as a list, overload it so that (:) appends something to the front of the list. It doesn't make a huge difference, but it lets you think of operators as a vibe and go look up the implementation elsewhere. I think operators from the core lang should be overloadable.