Really great and interesting blog post! The different categories of domain types identified all seem useful. It's clear how practical these ideas can be when im

Really great and interesting blog post! The different categories of domain types identified all seem useful. It's clear how practical these ideas can be when implementing or thinking about domain-specific types. I'll definitely be keeping these terms in mind for future programming. > Identifiers have no structure, i.e., we don’t care about their internal representation. The only fundamental requirement is the ability to compare values of those types for equality. This lack of structure suggests an appropriate mathematical model for such types: a set, a collection of distinct objects. I don't understand what this is trying to say and this "mathematical model" of sets doesn't seem to be applied further on. In math, objects are usually always assumed to have a notion of equality, so I don't see how that alone implies a set. A mathematical abstraction that matches the `Eq` trait would be a setoid. The `LocusLike` trait is a lot like a metric space with a total order. I wonder if it can be implemented by things that are not basically numbers under the hood (not that it needs to, just curious)? > Unlike design patterns, the universal domain types are based on mathematical abstractions and can be specified precisely. I feel like this is over-selling it a bit. I think the ideas are great but, at least as presented here, I don't think they are rigorous enough to deserve the label "mathematical abstractions".