5 ms·

Lists aren't immutable in Lisp, though. More precisely, Lisp doesn't have lists: it has chains of mutable cons cells.

ScottBurson 10y ago
They're not technically immutable, but culturally Lisp programmers are not in the habit of mutating lists unless they know where and for what purpose the list was created. Mutating some list whose provenance you don't know -- maybe you got it by calling some library function that doesn't explicitly promise to return a freshly consed list -- is a bad idea, and experienced Lisp programmers know this instinctively. So in practice you can often get away with pretending the lists you create are immutable, if that's what you want to do.
- catnaroek 10y ago
  Culture isn't something I can take into account when reasoning about what a piece of code means. The actual semantics of the programming language in question is all I really have.
  - ScottBurson 10y ago
    I doubt that. I think it would take too long to work out the meaning of every piece of code you see from first principles. I think any competent programmer has a large collection of unconscious heuristics they use to understand code. Learning to write code in such a way that the reader's heuristics will not mislead them is, I think, a big part of becoming a software engineer. I was just trying to describe the state of practice in the Lisp world. I do agree that Lisp benefits from more functional data structures -- that's why I wrote FSet [0]! I would point out, though, that since Lisp lacks any kind of access control, there's nothing besides common sense and convention that prevents FSet client code from mucking about inside the guts of the FSet data structures. It would be a stupid thing to do, and everybody knows that, but the language doesn't prevent it. So the situation is not that different with FSet collections than it is with lists of unknown provenance. Even in languages that nominally support access control, like C++ and Java, you can usually still get around it with casting or reflection. Most people know that they should play games like that only in very specific circumstances. [0] https://github.com/slburson/fset https://github.com/slburson/fset
    - catnaroek 10y ago
      > I think it would take too long to work out the meaning of every piece of code you see from first principles. Just as in mathematics, once you've proven something, you can reuse the result as often as you want. But “the community always does this” isn't a proof. > I do agree that Lisp benefits from more functional data structures (...) there's nothing besides common sense and convention that prevents FSet client code from mucking about inside the guts of the FSet data structures. Then Lisp doesn't have functional data structures. That's no surprise, Lisp has no more compound values than Python or Ruby do - that is, none. > Even in languages that nominally support access control, like C++ and Java, you can usually still get around it with casting or reflection. Standard ML actually has type abstraction, and, once you've made something abstract, there's no way clients can inspect it. No downcasts, no reflection, no anything - abstract means abstract.
      - ScottBurson 10y ago
        > Then Lisp doesn't have functional data structures. That's no surprise, Lisp has no more compound values than Python or Ruby do - that is, none. Ah, the arrogance of youth.
        catnaroek 10y ago
        It isn't arrogance, it's just the semantics of the programming languages in question. Programming languages being such fundamental tools, you would think every programmer should understand them well, but that is far from being the case. It is tempting to blame programmers, but the real culprit is the subtlety and depth of the topic. Two great resources to get started are https://www.amazon.com/dp/0262201755/ https://www.amazon.com/dp/0262201755/ and https://www.amazon.com/dp/0262690764/ https://www.amazon.com/dp/0262690764/ Anyway. A value is something you can bind to a variable. Unfortunately, you can't bind the list [1,2,3] (or whatever syntax you might prefer) to a variable in either Python or Lisp, because those languages simply don't have lists (or any other kind of compound value).
        ScottBurson 10y ago
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

They're not technically immutable, but culturally Lisp programmers are not in the habit of mutating lists unless they know where and for what purpose the list was created. Mutating some list whose provenance you don't know -- maybe you got it by calling some library function that doesn't explicitly promise to return a freshly consed list -- is a bad idea, and experienced Lisp programmers know this instinctively. So in practice you can often get away with pretending the lists you create are immutable, if that's what you want to do.

catnaroek 10y ago
Culture isn't something I can take into account when reasoning about what a piece of code means. The actual semantics of the programming language in question is all I really have.
- ScottBurson 10y ago
  I doubt that. I think it would take too long to work out the meaning of every piece of code you see from first principles. I think any competent programmer has a large collection of unconscious heuristics they use to understand code. Learning to write code in such a way that the reader's heuristics will not mislead them is, I think, a big part of becoming a software engineer. I was just trying to describe the state of practice in the Lisp world. I do agree that Lisp benefits from more functional data structures -- that's why I wrote FSet [0]! I would point out, though, that since Lisp lacks any kind of access control, there's nothing besides common sense and convention that prevents FSet client code from mucking about inside the guts of the FSet data structures. It would be a stupid thing to do, and everybody knows that, but the language doesn't prevent it. So the situation is not that different with FSet collections than it is with lists of unknown provenance. Even in languages that nominally support access control, like C++ and Java, you can usually still get around it with casting or reflection. Most people know that they should play games like that only in very specific circumstances. [0] https://github.com/slburson/fset https://github.com/slburson/fset
  - catnaroek 10y ago
    > I think it would take too long to work out the meaning of every piece of code you see from first principles. Just as in mathematics, once you've proven something, you can reuse the result as often as you want. But “the community always does this” isn't a proof. > I do agree that Lisp benefits from more functional data structures (...) there's nothing besides common sense and convention that prevents FSet client code from mucking about inside the guts of the FSet data structures. Then Lisp doesn't have functional data structures. That's no surprise, Lisp has no more compound values than Python or Ruby do - that is, none. > Even in languages that nominally support access control, like C++ and Java, you can usually still get around it with casting or reflection. Standard ML actually has type abstraction, and, once you've made something abstract, there's no way clients can inspect it. No downcasts, no reflection, no anything - abstract means abstract.
    - ScottBurson 10y ago
      > Then Lisp doesn't have functional data structures. That's no surprise, Lisp has no more compound values than Python or Ruby do - that is, none. Ah, the arrogance of youth.
      - catnaroek 10y ago
        It isn't arrogance, it's just the semantics of the programming languages in question. Programming languages being such fundamental tools, you would think every programmer should understand them well, but that is far from being the case. It is tempting to blame programmers, but the real culprit is the subtlety and depth of the topic. Two great resources to get started are https://www.amazon.com/dp/0262201755/ https://www.amazon.com/dp/0262201755/ and https://www.amazon.com/dp/0262690764/ https://www.amazon.com/dp/0262690764/ Anyway. A value is something you can bind to a variable. Unfortunately, you can't bind the list [1,2,3] (or whatever syntax you might prefer) to a variable in either Python or Lisp, because those languages simply don't have lists (or any other kind of compound value).
        ScottBurson 10y ago

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