4 ms·

In my understanding, in LISP-59, the only list-modification symbols are FIRST and REST. This makes me want to claim that in the one true Lisp, there are no mut

by jholman 10y ago

In my understanding, in LISP-59, the only list-modification symbols are FIRST and REST. This makes me want to claim that in the one true Lisp, there are no mutable cells. Actual useful implementations of Lisp, of course, may vary. edit: s/list/Lisp/ in a particular place

catnaroek 10y ago
Does it make sense to distinguish between “this 2” and “that 2”? Of course not! And indeed Lisp doesn't let you make that silly distinction. Yet somehow it lets you distinguish between “this (list 1 2 3)” and “that (list 1 2 3)”. Distinguishing between copies of the same value isn't “useful”, it's a pain, because you need to jump to a metalanguage (say, Hoare logic) to get the values you actually want.
- jholman 10y ago
  I don't understand what this has to do with whether or not lists are mutable in lisp. It's possible that you were misled by a silly typo in my comment, which I have just fixed. With that in mind, could you clarify?
  - catnaroek 10y ago
    > I don't understand what this has to do with whether or not lists are mutable in lisp. Lists aren't mutable in any language. A list is a sequence of elements. A different sequence is a different list. Some languages simply don't have lists.
    - deleted 10y ago
      [deleted]
- ScottBurson 10y ago
  > Does it make sense to distinguish between “this 2” and “that 2”? Of course not! And indeed Lisp doesn't let you make that silly distinction. It does, actually, if the integer is large enough: > (ash 1 100) 1267650600228229401496703205376 ; 2 ^ 100 > (eq (ash 1 100) (ash 1 100)) NIL This is why you should use 'eql', not 'eq', to compare integers. But again: Lisp programmers have to know that. We're back to culture and convention. So much the worse for Lisp, I suppose you would say, and perhaps you have a point. Lisp is not Haskell. I don't entirely disagree with you; it would be nice if Lisp had an immutable list type. (Like FSet seqs [0].) But again, in practice, it's not as much of a deficiency as you seem to think. [0] https://github.com/slburson/fset https://github.com/slburson/fset
  - catnaroek 10y ago
    > It does, actually, if the integer is large enough: (snippet) Wow, this is even more broken than I previously thought. > Lisp is not Haskell. Haskell is broken too, only in a different way: Since when does it make sense to have a value that's simultaneously a number, a string, a function and pretty much anything else imaginable? (`undefined`) > But again, in practice, it's not as much of a deficiency as you seem to think. It causes difficulties when you want to reason rigorously about your code.
    - lispm 10y ago
      > It causes difficulties when you want to reason rigorously about your code That's what he said. In practice it doesn't matter.
      - catnaroek 10y ago
        > In practice it doesn't matter. I reason rigorously about my code in practice.
        lispm 10y ago
        I don't.
        tome 10y ago
        I still haven't fully grasped what aspect of Haskell means you can't rigorously reason about your code. I'm pretty sure you don't mean space leaks, and I'm pretty sure you don't mean global coherence of type classes, which are the two most popular complaints about reasoning about Haskell. Other than that, can't you just say "this piece of code is at least as defined as the equivalent in a strict language" and leave it at that? What can go wrong?
        catnaroek 10y ago
        > I still haven't fully grasped what aspect of Haskell means you can't rigorously reason about your code. Oh, that particular criticism wasn't aimed at Haskell, but rather at languages without compound values. And I never said you can't reason rigorously about code written in such languages. You can, but it isn't very pleasant. > I'm pretty sure you don't mean global coherence of type classes, which are the two most popular complaints about reasoning about Haskell. Far more serious one: Haskell doesn't have a type whose value inhabitants are the integers and nothing else. I would like to say “even Lisp has that”, but nope, it doesn't either: https://news.ycombinator.com/item?id=12328095 https://news.ycombinator.com/item?id=12328095

by jholman 10y ago

catnaroek 10y ago

Does it make sense to distinguish between “this 2” and “that 2”? Of course not! And indeed Lisp doesn't let you make that silly distinction. Yet somehow it lets you distinguish between “this (list 1 2 3)” and “that (list 1 2 3)”. Distinguishing between copies of the same value isn't “useful”, it's a pain, because you need to jump to a metalanguage (say, Hoare logic) to get the values you actually want.

jholman 10y ago
I don't understand what this has to do with whether or not lists are mutable in lisp. It's possible that you were misled by a silly typo in my comment, which I have just fixed. With that in mind, could you clarify?
- catnaroek 10y ago
  > I don't understand what this has to do with whether or not lists are mutable in lisp. Lists aren't mutable in any language. A list is a sequence of elements. A different sequence is a different list. Some languages simply don't have lists.
  - deleted 10y ago
    [deleted]
ScottBurson 10y ago
> Does it make sense to distinguish between “this 2” and “that 2”? Of course not! And indeed Lisp doesn't let you make that silly distinction. It does, actually, if the integer is large enough: > (ash 1 100) 1267650600228229401496703205376 ; 2 ^ 100 > (eq (ash 1 100) (ash 1 100)) NIL This is why you should use 'eql', not 'eq', to compare integers. But again: Lisp programmers have to know that. We're back to culture and convention. So much the worse for Lisp, I suppose you would say, and perhaps you have a point. Lisp is not Haskell. I don't entirely disagree with you; it would be nice if Lisp had an immutable list type. (Like FSet seqs [0].) But again, in practice, it's not as much of a deficiency as you seem to think. [0] https://github.com/slburson/fset https://github.com/slburson/fset
- catnaroek 10y ago
  > It does, actually, if the integer is large enough: (snippet) Wow, this is even more broken than I previously thought. > Lisp is not Haskell. Haskell is broken too, only in a different way: Since when does it make sense to have a value that's simultaneously a number, a string, a function and pretty much anything else imaginable? (`undefined`) > But again, in practice, it's not as much of a deficiency as you seem to think. It causes difficulties when you want to reason rigorously about your code.
  - lispm 10y ago
    > It causes difficulties when you want to reason rigorously about your code That's what he said. In practice it doesn't matter.
    - catnaroek 10y ago
      > In practice it doesn't matter. I reason rigorously about my code in practice.
      - lispm 10y ago
        I don't.
      - tome 10y ago
        I still haven't fully grasped what aspect of Haskell means you can't rigorously reason about your code. I'm pretty sure you don't mean space leaks, and I'm pretty sure you don't mean global coherence of type classes, which are the two most popular complaints about reasoning about Haskell. Other than that, can't you just say "this piece of code is at least as defined as the equivalent in a strict language" and leave it at that? What can go wrong?
        catnaroek 10y ago
        > I still haven't fully grasped what aspect of Haskell means you can't rigorously reason about your code. Oh, that particular criticism wasn't aimed at Haskell, but rather at languages without compound values. And I never said you can't reason rigorously about code written in such languages. You can, but it isn't very pleasant. > I'm pretty sure you don't mean global coherence of type classes, which are the two most popular complaints about reasoning about Haskell. Far more serious one: Haskell doesn't have a type whose value inhabitants are the integers and nothing else. I would like to say “even Lisp has that”, but nope, it doesn't either: https://news.ycombinator.com/item?id=12328095 https://news.ycombinator.com/item?id=12328095