5 ms·

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 syntactica

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
        >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. So long as the actual semantics (how the language behaves) stays the same, you can interpret it in your head any way you want. You don't think of lists as a string of pointers when evaluating ML, and it's the same thing. >In Lisp, a cons cell is an object. In ML, a cons cell is a value. That's not the earthshaking difference you seem to think it is. In fact, values and objects are two aspects of the same thing. At the end of the day, lists are still chains of pointers, mutable or no, "object" or "value" (and I have to put it in quotes because your definition isn't in any way the common one). I give up. Your mental model seems to be horrifyingly warped and broken, but it seems to accurately model computation, so it really doesn't matter.
        catnaroek 10y ago
        > You don't think of lists as a string of pointers when evaluating ML, No, it's not. The Definition of Standard ML says absolutely nothing about lists or strings being implemented as pointers. Lists and strings are values. > and it's the same thing. It's not. > That's not the earthshaking difference you seem to think it is. It is. Values have a nontrivial equational theory that enables two syntactically different programs to be deemed equal using local reasoning exclusively. That is, without observing the effect of a computation on its much larger context. This in turn enables much more aggressive optimizations, both by hand and automatic, than are possible if all you have is object identities. > In fact, values and objects are two aspects of the same thing. Nope. Values are the more fundamental notion, mathematically. Object identities are but a particular kind of value, and so are object states in any mathematically civilized language. > At the end of the day, lists are still chains of pointers, mutable or no, "object" or "value" (and I have to put it in quotes because your definition isn't in any way the common one). Lists aren't chains of pointers when I evaluate them on paper. A list is just a sequence of elements. But even when working on a computer, using actual lists has concrete benefits, for example, the compiler is free to apply optimizations like “gluing” consecutive nodes to improve locality of reference (in the generated program) and ease the job on the garbage collector (assuming the list is used in a single-threaded fashion). In the limit, it's as if I had used a C++-style `std::vector`! When all you have is object identities, this optimization is obviously unsound.

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
      >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. So long as the actual semantics (how the language behaves) stays the same, you can interpret it in your head any way you want. You don't think of lists as a string of pointers when evaluating ML, and it's the same thing. >In Lisp, a cons cell is an object. In ML, a cons cell is a value. That's not the earthshaking difference you seem to think it is. In fact, values and objects are two aspects of the same thing. At the end of the day, lists are still chains of pointers, mutable or no, "object" or "value" (and I have to put it in quotes because your definition isn't in any way the common one). I give up. Your mental model seems to be horrifyingly warped and broken, but it seems to accurately model computation, so it really doesn't matter.
      - catnaroek 10y ago
        > You don't think of lists as a string of pointers when evaluating ML, No, it's not. The Definition of Standard ML says absolutely nothing about lists or strings being implemented as pointers. Lists and strings are values. > and it's the same thing. It's not. > That's not the earthshaking difference you seem to think it is. It is. Values have a nontrivial equational theory that enables two syntactically different programs to be deemed equal using local reasoning exclusively. That is, without observing the effect of a computation on its much larger context. This in turn enables much more aggressive optimizations, both by hand and automatic, than are possible if all you have is object identities. > In fact, values and objects are two aspects of the same thing. Nope. Values are the more fundamental notion, mathematically. Object identities are but a particular kind of value, and so are object states in any mathematically civilized language. > At the end of the day, lists are still chains of pointers, mutable or no, "object" or "value" (and I have to put it in quotes because your definition isn't in any way the common one). Lists aren't chains of pointers when I evaluate them on paper. A list is just a sequence of elements. But even when working on a computer, using actual lists has concrete benefits, for example, the compiler is free to apply optimizations like “gluing” consecutive nodes to improve locality of reference (in the generated program) and ease the job on the garbage collector (assuming the list is used in a single-threaded fashion). In the limit, it's as if I had used a C++-style `std::vector`! When all you have is object identities, this optimization is obviously unsound.