4 ms·

> Whether or not the object is new in RAM is purely semantic. Well, we're arguing programming language semantics! And what matters isn't whether it's a new mem

> Whether or not the object is new in RAM is purely semantic. Well, we're arguing programming language semantics! And what matters isn't whether it's a new memory block in RAM, which is an implementation detail, but rather whether the language will treat the new value or object as equal to anything that previously existed. > It's the same values. Can you bind the “value” to a variable?

qwertyuiop924 10y ago
I can bind the concrete representation of it returned by map to a variable, which is then equal to all other concrete representations of that value. Same as rust, or any other programming language.
- catnaroek 10y ago
  > I can bind the concrete representation of it returned by map to a variable, which is then equal to all other concrete representations of that value. What you're actually binding to a variable is just the identity of the first cons cell in the “list”. That's by no means an actual list value. The difference will be exposed as clearly as daylight if you mutate the cons cell.
  - qwertyuiop924 10y ago
    Yes, because that's how lists work. Just like in Haskell.
    - catnaroek 10y ago
      Nope. Haskell doesn't expose the physical identity of anything that isn't a reference cell (STRef, IORef, etc.). It's not even a type error - there's syntactically no way to query it. You just operate on values directly. The same is true in SML. Even objects are manipulated via their identities, which are values. Because values are a useful abstraction.
      - qwertyuiop924 10y ago
        That isn't what I meant. What I meant was that lists are kept as a reference to the head cons cell, in every language that implements lists as singly-linked lists. That's just how it works.
        catnaroek 10y ago
        > What I meant was that lists are kept as a reference to the head cons cell, in every language that implements lists as singly-linked lists. That's an implementation detail. Language abstractions are to be judged by their own semantics, not their possible implementations. And, FWIW, when I evaluate ML programs by hand on a piece of paper, lists aren't implemented as references to anything - a list is just a sequence of elements. On the other hand, if I had to evaluate Lisp programs on paper (thank goodness I don't have to!), object identities would still appear all over the place.
        qwertyuiop924 10y ago
        >when I evaluate ML programs by hand on a piece of paper, lists aren't implemented as references to anything - a list is just a sequence of elements. Well, yeah. Jusr like when I evaluate Lisp. But the idea of a cons cell is inherent to ML's list struture: They call it the cons operator for a reason.
        catnaroek 10y ago
        > Well, yeah. Jusr like when I evaluate Lisp. Then you're not really evaluating Lisp programs according to Lisp's well-defined semantics. Changing the semantics of a language makes the result a different language. > But the idea of a cons cell is inherent to ML's list struture: They call it the cons operator for a reason. Yep, but “cons cell” means completely different things in Lisp and ML. In Lisp, a cons cell is an object. In ML, a cons cell is a value.
        qwertyuiop924 10y ago

qwertyuiop924 10y ago

I can bind the concrete representation of it returned by map to a variable, which is then equal to all other concrete representations of that value. Same as rust, or any other programming language.

catnaroek 10y ago
> I can bind the concrete representation of it returned by map to a variable, which is then equal to all other concrete representations of that value. What you're actually binding to a variable is just the identity of the first cons cell in the “list”. That's by no means an actual list value. The difference will be exposed as clearly as daylight if you mutate the cons cell.
- qwertyuiop924 10y ago
  Yes, because that's how lists work. Just like in Haskell.
  - catnaroek 10y ago
    Nope. Haskell doesn't expose the physical identity of anything that isn't a reference cell (STRef, IORef, etc.). It's not even a type error - there's syntactically no way to query it. You just operate on values directly. The same is true in SML. Even objects are manipulated via their identities, which are values. Because values are a useful abstraction.
    - qwertyuiop924 10y ago
      That isn't what I meant. What I meant was that lists are kept as a reference to the head cons cell, in every language that implements lists as singly-linked lists. That's just how it works.
      - catnaroek 10y ago
        > What I meant was that lists are kept as a reference to the head cons cell, in every language that implements lists as singly-linked lists. That's an implementation detail. Language abstractions are to be judged by their own semantics, not their possible implementations. And, FWIW, when I evaluate ML programs by hand on a piece of paper, lists aren't implemented as references to anything - a list is just a sequence of elements. On the other hand, if I had to evaluate Lisp programs on paper (thank goodness I don't have to!), object identities would still appear all over the place.
        qwertyuiop924 10y ago
        >when I evaluate ML programs by hand on a piece of paper, lists aren't implemented as references to anything - a list is just a sequence of elements. Well, yeah. Jusr like when I evaluate Lisp. But the idea of a cons cell is inherent to ML's list struture: They call it the cons operator for a reason.
        catnaroek 10y ago
        > Well, yeah. Jusr like when I evaluate Lisp. Then you're not really evaluating Lisp programs according to Lisp's well-defined semantics. Changing the semantics of a language makes the result a different language. > But the idea of a cons cell is inherent to ML's list struture: They call it the cons operator for a reason. Yep, but “cons cell” means completely different things in Lisp and ML. In Lisp, a cons cell is an object. In ML, a cons cell is a value.
        qwertyuiop924 10y ago