4 ms·

Returning a compound object, obviously. And Common Lisp's `mapcar` isn't a mathematical function.

qwertyuiop924 10y ago
>Common Lisp's `mapcar` isn't a mathematical function. Yes it is. It takes a function and a list as input, and outputs a list of the results of that function applied to each element of the list. It has no side effects, it maps a domain to a range, and it's referentially transparent, so long as the function you passed to it is.
- catnaroek 10y ago
  > It has no side effects It has the side effect of creating new object identities, at least when its “list” argument isn't `nil`. That identity is a completely new value that didn't exist before `mapcar` was called. > it maps a domain to a range In mathematics, the domain and codomain of a function are sets. Sets don't exist “in time”, let alone get new elements in time.
  - qwertyuiop924 10y ago
    Oh for god's sake... Yes, the value did conceptually exist before the function ran. Or is Haskell's map equally not functional? And the set for map doesn't grow over time.
    - catnaroek 10y ago
      > 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

>Common Lisp's `mapcar` isn't a mathematical function. Yes it is. It takes a function and a list as input, and outputs a list of the results of that function applied to each element of the list. It has no side effects, it maps a domain to a range, and it's referentially transparent, so long as the function you passed to it is.

catnaroek 10y ago
> It has no side effects It has the side effect of creating new object identities, at least when its “list” argument isn't `nil`. That identity is a completely new value that didn't exist before `mapcar` was called. > it maps a domain to a range In mathematics, the domain and codomain of a function are sets. Sets don't exist “in time”, let alone get new elements in time.
- qwertyuiop924 10y ago
  Oh for god's sake... Yes, the value did conceptually exist before the function ran. Or is Haskell's map equally not functional? And the set for map doesn't grow over time.
  - catnaroek 10y ago
    > 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