Hacker News new | past | comments | ask | show | jobs | submit login

The main takeaway from this is that having one somewhat ill-defined definition of equality over the whole language ecosystem is a bad idea. There is a reason why typical LISP has 5+ different notions of equality in the base language.

The typical reason for having some kind of language-wide notion of equality (and hash code) is to support some kind of general collections library. If the objects that have some kind of general equality relationship defined by anything else but their identity are mutable then the whole thing invariably breaks down. And on the other hand you often want collection that uses some completely arbitrary notion of equality. This means that good design of collections library should not dictate any interface for the equality concept on the elements and use plain object identity by default while allowing overriding of that not per class of the elements, but per usage of the collection.




OCaml solves this elegantly by making the equality functions parameters to the constructor of the collection type.


Completely agree. I’ve been working on a Common Lisp collection library, and I went out of my way to make the element comparison function a parameter at data structure init time. If someone disagrees with my very strict definition of equality, they are welcome to provide their own comparison function! It always bothered me very much that FSet (the most prominent collections library for CL) used a definition of equality that is based on the a specific generic function that couldn’t be replaced. The icing on the cake is that FSet’s equality generic function messes up with derived classes. Oops.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: