Sure, here’s my take.

From a functional point of view, I think of the protocol as the abstraction itself, defining what it means to be equal. I use Eq.Utils as a convenient place to keep helper functions that work with Eq.

I had considered naming Eq as Eq.Protocol, but in the end I leaned away from that. I felt that framing treated the protocol more like an interface for modules to implement, which doesn’t quite match how I think about the abstraction.

The combination of defdelegate eq?(a, b), to: Eq.Protocol and eq?(a, b, comparator) is behaviorally equivalent to my approach, but to me it reads a bit like OOP. Nothing wrong with that, just a different frame.

But those are really just semantics, the real difference is in how we handle the third argument. You’re passing a function, while I’m passing a map with an :eq? key that holds the function. Treating the comparison logic as data makes it easier to compose later. For instance, check out the Funx monoid.

You might find AI Tutor for Functional Programming - Funx , interesting. Feed in your example and get Claude to focus on the different eq?/3 functions. If it is attending to the usage rules, it does a pretty good job of explaining why you might choose one over the other.