2 ms·

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 rus

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
        >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.

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
        >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.