4 ms·

> No, it isn't. I entirely fail to see where rust has compound values. struct Vec2(usize, usize); let origin = Vec2(0, 0); // value let center = Ve

> No, it isn't. I entirely fail to see where rust has compound values. struct Vec2(usize, usize); let origin = Vec2(0, 0); // value let center = Vec2(0, 0); // same value let faraway = Vec2(123,456); // another value > I think you want the programming language to decide what equality operator to use for you. I want the programming language to let me compare the values I care about. I don't want to worry about irrelevant details, like the location, physical or abstract, where a value's representation is stored. Of course, I do care about the physical identity of objects. But objects are not values! > I fail to see how values are any more "make-belive" in Lisp than in any other language. The language forces me to care about a low-level implementation detail. Namely, that the compound values in my problem domain are realized as compound objects in Lisp. It fits the definition of “make-believe”. In any case, it wasn't my intention to single Lisp out. Most languages out there only have make-believe compound values.

qwertyuiop924 10y ago
here's something fun about that rust example: struct Vec2(usize, usize); let a = Vec2(0,0); let b = Vec2(0,0); a == b //true &a as *const usize == &b as *const usize //false And now the (near enough for this example) equivalent Scheme: (define-record vec2 x y) ;;There's no anonymous values in the default scheme record implementation, but it makes no difference for our purposes (define A (make-vec2 0 0)) (define B (make-vec2 0 0)) ;;No constants at a language level, but constant values are uppercase by convention. (equal? A B) ;true (eq? A B) ;false True, the syntax is a bit different (rust doesn't like identity checks), but the semantics, save the above notes, are identical. What you call "values" in one language are identical to what you call "objects" in another. Just use equal like you would in any other language. >I want the programming language to let me compare the values I care about. I don't want to worry about irrelevant details, like the location, physical or abstract, where a value's representation is stored. Than just use equal. >The language forces me to care about a low-level implementation detail You need only care about it if you want to. If you don't, just use equal. Are you starting to see a pattern?
- catnaroek 10y ago
  > here's something fun about that rust example: &a as *const usize == &b as *const usize //false Yes, in Rust, `a` and `b` are objects with identity. But their state is a compound value that can be easily copied to a different object, passed by value to a function, etc. > You need only care about it if you want to. If you don't, just use equal. A high-level language is supposed to provide abstractions that don't leak.
  - qwertyuiop924 10y ago
    >Yes, in Rust, `a` and `b` are objects with identity. But their state is a compound value that can be easily copied to a different object, passed by value to a function, etc. And you can do the same in Lisp, but, like Python and other languages, it doesn't happen for you. >A high-level language is supposed to provide abstractions that don't leak That's not a leak: It's an escape valve. eq is an escape from the world of values for when you have to care about objects, the same way C has the & unary operator, and rust has the *const cast, and ruby has the equals? message, and python has the is operator. The only reason Haskell doesn't have the same is that it's pure, at least in theory, so there isn't a meaningful distinction. But in languages where state is mutatable, you need eq, or an equivalent, for when you have to care about object identity.
    - catnaroek 10y ago
      > And you can do the same in Lisp, but, like Python and other languages, it doesn't happen for you. No, the state of a Lisp or Python object isn't a value. You can't pass it around without manually deep-cloning everything. Cloning a value doesn't even make sense - there's always only one of it! > The only reason Haskell doesn't have the same is that it's pure, at least in theory, so there isn't a meaningful distinction. ML isn't pure, but it confines physical equality to mutable objects, and not everything is a mutable object. This discussion has absolutely nothing to do with purity. > But in languages where state is mutatable, you need eq, or an equivalent, for when you have to care about object identity. Haskell and ML have lots of mutable state, and don't need a distinction between eq and equal. The single equality testing operator does the right thing on values of different types.

qwertyuiop924 10y ago

here's something fun about that rust example: struct Vec2(usize, usize); let a = Vec2(0,0); let b = Vec2(0,0); a == b //true &a as *const usize == &b as *const usize //false And now the (near enough for this example) equivalent Scheme: (define-record vec2 x y) ;;There's no anonymous values in the default scheme record implementation, but it makes no difference for our purposes (define A (make-vec2 0 0)) (define B (make-vec2 0 0)) ;;No constants at a language level, but constant values are uppercase by convention. (equal? A B) ;true (eq? A B) ;false True, the syntax is a bit different (rust doesn't like identity checks), but the semantics, save the above notes, are identical. What you call "values" in one language are identical to what you call "objects" in another. Just use equal like you would in any other language. >I want the programming language to let me compare the values I care about. I don't want to worry about irrelevant details, like the location, physical or abstract, where a value's representation is stored. Than just use equal. >The language forces me to care about a low-level implementation detail You need only care about it if you want to. If you don't, just use equal. Are you starting to see a pattern?

catnaroek 10y ago
> here's something fun about that rust example: &a as *const usize == &b as *const usize //false Yes, in Rust, `a` and `b` are objects with identity. But their state is a compound value that can be easily copied to a different object, passed by value to a function, etc. > You need only care about it if you want to. If you don't, just use equal. A high-level language is supposed to provide abstractions that don't leak.
- qwertyuiop924 10y ago
  >Yes, in Rust, `a` and `b` are objects with identity. But their state is a compound value that can be easily copied to a different object, passed by value to a function, etc. And you can do the same in Lisp, but, like Python and other languages, it doesn't happen for you. >A high-level language is supposed to provide abstractions that don't leak That's not a leak: It's an escape valve. eq is an escape from the world of values for when you have to care about objects, the same way C has the & unary operator, and rust has the *const cast, and ruby has the equals? message, and python has the is operator. The only reason Haskell doesn't have the same is that it's pure, at least in theory, so there isn't a meaningful distinction. But in languages where state is mutatable, you need eq, or an equivalent, for when you have to care about object identity.
  - catnaroek 10y ago
    > And you can do the same in Lisp, but, like Python and other languages, it doesn't happen for you. No, the state of a Lisp or Python object isn't a value. You can't pass it around without manually deep-cloning everything. Cloning a value doesn't even make sense - there's always only one of it! > The only reason Haskell doesn't have the same is that it's pure, at least in theory, so there isn't a meaningful distinction. ML isn't pure, but it confines physical equality to mutable objects, and not everything is a mutable object. This discussion has absolutely nothing to do with purity. > But in languages where state is mutatable, you need eq, or an equivalent, for when you have to care about object identity. Haskell and ML have lots of mutable state, and don't need a distinction between eq and equal. The single equality testing operator does the right thing on values of different types.