> Yes, but you seemed to have an objection to eq existing at all. I have an objection to equality (and, more generally, value manipulation) being broken. If yo

> Yes, but you seemed to have an objection to eq existing at all. I have an objection to equality (and, more generally, value manipulation) being broken. If you can't define it correctly, then don't define it at all. > No, it isn't. Because sometimes you need that information. Which is why refcells exist in the first place. You still misunderstand. Reference cells only let me manipulate the physical identity of objects. Normal values don't have a physical identity. Just like numbers don't have a physical identity in Lisp - except this applies to a much larger class of values in ML. > Every language, even your beloved ML, has this valve in some way. There is no abstraction violation in ML: You can't query the physical location of a list in ML. You can only query the physical location of an object whose state happens to be a list. A `foo list` and a `foo list ref` are very different things, and the type checker will let you know if you accidentally conflate them. > Second off, that just seems like an argument for typing, Yes. (Just to be clear: whether it's static or dynamic typing matters very little.) > dynamic dispatch, Dynamic dispatch is only one possible implementation strategy. Another is monomorphization, which removes all second-class polymorphism at compile time, but requires whole program analysis. Standard ML doesn't have first-class polymorphism. In any case, as a language user, I absolutely don't care how this is implemented. That's a problem for compiler writers. As Dijkstra said, the specification acts as a contract between users and implementors, defining precisely the rights and responsibilities of each part. > and a ref type. Yes. > As for the most convenient solution in lisp, do you want convenient, or efficent? Both. This dichotomy is an argument by lack of imagination. > It took one extra line of code and wasn't "tricky" at all. Have you ever tried actually proving anything about code that uses call/cc? Effectively, you need to first CPS-convert your code, and only then prove whatever you want to prove about the result of such CPS conversion. If testing two data structures for equality requires call/cc, the language is broken. > Sure, we don't have types, so it's not automatic, Let me repeat: This isn't an argument over static types. What I'm asking for can be done correctly in a dynamically typed setting too. Lisp, for some reason that's hard to understand, chooses not to. > but it's still pretty simple. Writing code that's generic over a comparator (more generally, generic over the realization of some algebraic or relational structure) is tedious and easy to do wrong in Lisp.