3 ms·

> And in the PDP-11 decade, I believe there was much wider awareness of Lisp. (I was a kid then, so that's just my impression. I don't actually know.) I was no

> And in the PDP-11 decade, I believe there was much wider awareness of Lisp. (I was a kid then, so that's just my impression. I don't actually know.) I was not around but from the literature it seems Lisp trolls existed even back then - for example Ted Nelson's Computer Lib / Dream Machines contains some very negative and very mistaken statements about Lisp, and it was published in 1974. > Lisp allocates all the time. You have to work hard if you want it not to. So if you want explicit allocation, you'd have to invoke it all the time, and it would really get in the way - far more than it does in C. (Far more things are allocated in Lisp than in C... Lisp, to my (very limited) knowledge, doesn't have a way to treat an allocated block of memory as anything other than a cons pair. Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling.

PuercoPop 9y ago
> Lisp trolls existed even back the Recently while reading, Appel's Compiling with Continuations, I read some mistaken claims about Lisp and scope, one doesn't have to be a troll, which requires intent, to make ignorant claims about Lisp, parsing or any subject. Although the amount of ridiculous arguments from people who clearly haven't used it (or at most used it very briefly) does make one's blood boil at times.
- fusiongyro 9y ago
  I agree, but just because I'm curious, what did Appel say? Different dialects of Lisp have had different scoping rules, but beyond that I don't know what is true or false. I believe earlier ones were dynamically scoped, because I vaguely recollect that lexical scoping was an important change in Common Lisp and Scheme. Of course Common Lisp has a special way to ask for dynamic scope.
  - PuercoPop 9y ago
    Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC) Here is another one I found looking for the quote I was remembering. > "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haskell, but not Pascal and Lisp.
    - fusiongyro 9y ago
      Wow. Well, at one time, maybe Lisp did not have that? It certainly did by the time this book was written though.
      - kazinator 9y ago
        "Lisp" still hasn't; it is a family which comprises various dialects, many of which have lexical scoping, but some of which don't, like Emacs Lisp (which only had dynamic binding until recently and now supports lexical scoping, but not by default).
        fusiongyro 9y ago
        My comment was directed at the quote about higher-order functions, which is a more legitimately surprising thing than something about scope. And of course we're talking about whatever would have been considered "Lisp" by Appel in 1992, even though you and I might know better and be more precise today.
AnimalMuppet 9y ago
> Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling. Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said. My understanding is, 1, that every newly-created cons pair requires an allocation, 2, that every new list entry is a new cons pair, and 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently. Which, of those statements, do you consider to be wrong, and why?
- sedachv 9y ago
  > Which, of those statements, do you consider to be wrong, and why? Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation. I am going to assume you need a stdlib.h refresher: void *malloc(size_t size); void free(void *ptr); How do you think free works? How would you write a linked list implementation in C? I just happened to have done some software archaeology on a Lisp implementation without a garbage collector a while ago (https://github.com/vsedach/Thinlisp-1.1 https://github.com/vsedach/Thinlisp-1.1), and the memory allocation and lifetime management is exactly the same there as in C++ - manual management and dynamic extent regions (RAII). Now I really want to get pedantic with each of your points, because individually each is wrong in interesting ways: > 1, that every newly-created cons pair requires an allocation This statement is a redundant tautology ("every new allocation requires an allocation"), but even the correctly phrased assertion that "CONS always allocates" is not always true: https://en.wikipedia.org/wiki/Hash_consing https://en.wikipedia.org/wiki/Hash_consing http://3e8.org/pub/scheme/doc/lisp-pointers/v1i3/p17-white.pdf http://3e8.org/pub/scheme/doc/lisp-pointers/v1i3/p17-white.p... > 2, that every new list entry is a new cons pair Again, redundant, and again, not always true, because of hash consing and CDR coding: https://en.wikipedia.org/wiki/CDR_coding https://en.wikipedia.org/wiki/CDR_coding > 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently. If you do not need to allocate lists, do not allocate lists. There is no "normal" way of writing code that exists outside of what your performance requirements are, what the language semantics are, and what the language implementation provides in terms of those semantics. The only situation where you cannot avoid frequent allocations is when all the data structures are immutable.

PuercoPop 9y ago

> Lisp trolls existed even back the Recently while reading, Appel's Compiling with Continuations, I read some mistaken claims about Lisp and scope, one doesn't have to be a troll, which requires intent, to make ignorant claims about Lisp, parsing or any subject. Although the amount of ridiculous arguments from people who clearly haven't used it (or at most used it very briefly) does make one's blood boil at times.

fusiongyro 9y ago
I agree, but just because I'm curious, what did Appel say? Different dialects of Lisp have had different scoping rules, but beyond that I don't know what is true or false. I believe earlier ones were dynamically scoped, because I vaguely recollect that lexical scoping was an important change in Common Lisp and Scheme. Of course Common Lisp has a special way to ask for dynamic scope.
- PuercoPop 9y ago
  Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC) Here is another one I found looking for the quote I was remembering. > "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haskell, but not Pascal and Lisp.
  - fusiongyro 9y ago
    Wow. Well, at one time, maybe Lisp did not have that? It certainly did by the time this book was written though.
    - kazinator 9y ago
      "Lisp" still hasn't; it is a family which comprises various dialects, many of which have lexical scoping, but some of which don't, like Emacs Lisp (which only had dynamic binding until recently and now supports lexical scoping, but not by default).
      - fusiongyro 9y ago
        My comment was directed at the quote about higher-order functions, which is a more legitimately surprising thing than something about scope. And of course we're talking about whatever would have been considered "Lisp" by Appel in 1992, even though you and I might know better and be more precise today.

AnimalMuppet 9y ago

> Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling. Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said. My understanding is, 1, that every newly-created cons pair requires an allocation, 2, that every new list entry is a new cons pair, and 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently. Which, of those statements, do you consider to be wrong, and why?

sedachv 9y ago
> Which, of those statements, do you consider to be wrong, and why? Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation. I am going to assume you need a stdlib.h refresher: void *malloc(size_t size); void free(void *ptr); How do you think free works? How would you write a linked list implementation in C? I just happened to have done some software archaeology on a Lisp implementation without a garbage collector a while ago (https://github.com/vsedach/Thinlisp-1.1 https://github.com/vsedach/Thinlisp-1.1), and the memory allocation and lifetime management is exactly the same there as in C++ - manual management and dynamic extent regions (RAII). Now I really want to get pedantic with each of your points, because individually each is wrong in interesting ways: > 1, that every newly-created cons pair requires an allocation This statement is a redundant tautology ("every new allocation requires an allocation"), but even the correctly phrased assertion that "CONS always allocates" is not always true: https://en.wikipedia.org/wiki/Hash_consing https://en.wikipedia.org/wiki/Hash_consing http://3e8.org/pub/scheme/doc/lisp-pointers/v1i3/p17-white.pdf http://3e8.org/pub/scheme/doc/lisp-pointers/v1i3/p17-white.p... > 2, that every new list entry is a new cons pair Again, redundant, and again, not always true, because of hash consing and CDR coding: https://en.wikipedia.org/wiki/CDR_coding https://en.wikipedia.org/wiki/CDR_coding > 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently. If you do not need to allocate lists, do not allocate lists. There is no "normal" way of writing code that exists outside of what your performance requirements are, what the language semantics are, and what the language implementation provides in terms of those semantics. The only situation where you cannot avoid frequent allocations is when all the data structures are immutable.