4 ms·

> Or is Haskell's map equally not functional? Haskell's `map` is a function at the time it is called. If it is called a second time, and new objects were alloc

> Or is Haskell's map equally not functional? Haskell's `map` is a function at the time it is called. If it is called a second time, and new objects were allocated in between, then `map` is a different function, but still a function. > And the set for map doesn't grow over time. `mapcar` creates new object identities that didn't exist before. It's as effectful as it gets.

qwertyuiop924 10y ago
Whether or not the object is new in RAM is purely semantic. It's the same values. And whether they are eq is entirely irrelevant to this discussion.
- catnaroek 10y ago
  > 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.

qwertyuiop924 10y ago

Whether or not the object is new in RAM is purely semantic. It's the same values. And whether they are eq is entirely irrelevant to this discussion.

catnaroek 10y ago
> 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.