4 ms·

Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card,

by redahs 11y ago

Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card, GPU, etc) by simply expanding expressions using the built in syntax. This means it's necessary for LISPers to continually reinvent the input-output layer and add non referentially transparent features to the language borrowed from Java or C in order to do any useful work. Doing so is also contrary to the ideals of functional programming however, so they will continually overthrow the established LISP to invent a new one. edit: to downvoters, replace "you" with "language runtime implementers", and understand that this is not a normative assertion, but a descriptive theory to explain why we have seen a huge number of non-interoperable Lisp\Scheme implementations with minor differences over the years.

zeveb 11y ago
> Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card, GPU, etc) by simply expanding expressions using the built in syntax. What are you talking about? Common Lisp has built-in support for vectors: (let ((vector (make-array length :element-type 'unsigned-byte))) ;; do stuff with that flat array of bytes ;; … (replace ext:gpu vector)) (In this example, EXT:GPU is a chunk of memory which is overwritten by VECTOR; one might conceivably use COPY-SEQ instead of MAKE-ARRAY, and one might of course just operate on EXT:GPU) > Doing so is also contrary to the ideals of functional programming Lisp isn't about functional programming; Lisp is a multi-paradigm language, supporting imperative, functional and OO programming out of the box (and can of course be extended to support aspect-oriented programming, table-oriented programming or what-have-you).
- redahs 11y ago
  I would argue that a significant number of people were attracted to Lisp\Scheme variants over the years because of the promise of functional programming and the theoretical advantages of being to design programs using functional principles. The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value. Ideally we would be able to define a return value as a variable length sequence of constituent elements through recursive evaluation, where the process of evaluation is guaranteed to compactly allocate all of the constituent elements contiguously on the same location of the stack. This would allow the runtime implementation to directly copy the contents of a value of an arbitrary size to a necessary output device, so long as the runtime had access to a portable and functional definition of the value to be copied. Because the Lisp language family does not provide for this, there has been a need to continually invent new implementation variants which each model different internal machines for performing these tasks.
  - Arcanum-XIII 11y ago
    But... Lisp was never (except for clojure) sold as a functional language ! The ml family is more inline with what you think lisp are. Lisp are multi paradigm and that's one of their strong point - with macro.
  - zeveb 11y ago
    > The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value. I don't get what you're saying: REPLACE is bog-standard Common Lisp; it's not implementation-specific. You complained that it's not possible to produce a 'flat binary array suitable for direct copying to output device memory'; I demonstrated that it is. > Ideally we would be able to define a return value as a variable length sequence of constituent elements You can do that with '(simple-array unsigned-byte)… Seriously, Common Lisp was built to be an industrial-strength language: it can bit-blit with the best of 'em, as well as supporting high-level dynamic concepts. It's pretty cool!
    - redahs 11y ago
      > complained that it's not possible to produce a 'flat binary array suitable for direct copying to output device memory' I believe my mistake was using the term 'array' rather than 'string'. This should read it's not possible to define a 'flat binary string, of variable length, in a pure functional manner, through implicit concatenation, with the guarantee that every return value reduces to a binary string, using the commonly accepted semantics of s-expression evaluation common to all Lisps'. It certainly possible to build and process fixed size binary strings by adding, as I mentioned, "non referentially transparent features" to your language implementation, including Common Lisp's "replace" operation. However, since such semantics are procedural and imperative in nature, they do not lend themselves well to the production of concise and declarative definitions suitable for describing the encoding of formatted binary strings adhering to a specific protocol, such as what one might find in the documentation of protocols for mass communication, encryption, and long term storage. If they did, then we would most likely expect to see Scheme\Lisp\Clojure programmers of all varieties directly importing the same open protocol definitions from an established sources directly into their application codebases, and not repeatedly rewriting this functionality or relying on bindings to C\Java libraries. > Common Lisp was built to be an industrial-strength language I am not discussing the limitations of Common Lisp in particular, I am discussing the limitations of Lisp family of languages as a whole, and describing why there will most likely always be someone implementing a new slightly different variants of it, of which Common Lisp is but one example, and why it is unlikely that Lisp programmers will ever converge on one single language.

by redahs 11y ago

zeveb 11y ago

> Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card, GPU, etc) by simply expanding expressions using the built in syntax. What are you talking about? Common Lisp has built-in support for vectors: (let ((vector (make-array length :element-type 'unsigned-byte))) ;; do stuff with that flat array of bytes ;; … (replace ext:gpu vector)) (In this example, EXT:GPU is a chunk of memory which is overwritten by VECTOR; one might conceivably use COPY-SEQ instead of MAKE-ARRAY, and one might of course just operate on EXT:GPU) > Doing so is also contrary to the ideals of functional programming Lisp isn't about functional programming; Lisp is a multi-paradigm language, supporting imperative, functional and OO programming out of the box (and can of course be extended to support aspect-oriented programming, table-oriented programming or what-have-you).

redahs 11y ago
I would argue that a significant number of people were attracted to Lisp\Scheme variants over the years because of the promise of functional programming and the theoretical advantages of being to design programs using functional principles. The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value. Ideally we would be able to define a return value as a variable length sequence of constituent elements through recursive evaluation, where the process of evaluation is guaranteed to compactly allocate all of the constituent elements contiguously on the same location of the stack. This would allow the runtime implementation to directly copy the contents of a value of an arbitrary size to a necessary output device, so long as the runtime had access to a portable and functional definition of the value to be copied. Because the Lisp language family does not provide for this, there has been a need to continually invent new implementation variants which each model different internal machines for performing these tasks.
- Arcanum-XIII 11y ago
  But... Lisp was never (except for clojure) sold as a functional language ! The ml family is more inline with what you think lisp are. Lisp are multi paradigm and that's one of their strong point - with macro.
- zeveb 11y ago
  > The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value. I don't get what you're saying: REPLACE is bog-standard Common Lisp; it's not implementation-specific. You complained that it's not possible to produce a 'flat binary array suitable for direct copying to output device memory'; I demonstrated that it is. > Ideally we would be able to define a return value as a variable length sequence of constituent elements You can do that with '(simple-array unsigned-byte)… Seriously, Common Lisp was built to be an industrial-strength language: it can bit-blit with the best of 'em, as well as supporting high-level dynamic concepts. It's pretty cool!
  - redahs 11y ago
    > complained that it's not possible to produce a 'flat binary array suitable for direct copying to output device memory' I believe my mistake was using the term 'array' rather than 'string'. This should read it's not possible to define a 'flat binary string, of variable length, in a pure functional manner, through implicit concatenation, with the guarantee that every return value reduces to a binary string, using the commonly accepted semantics of s-expression evaluation common to all Lisps'. It certainly possible to build and process fixed size binary strings by adding, as I mentioned, "non referentially transparent features" to your language implementation, including Common Lisp's "replace" operation. However, since such semantics are procedural and imperative in nature, they do not lend themselves well to the production of concise and declarative definitions suitable for describing the encoding of formatted binary strings adhering to a specific protocol, such as what one might find in the documentation of protocols for mass communication, encryption, and long term storage. If they did, then we would most likely expect to see Scheme\Lisp\Clojure programmers of all varieties directly importing the same open protocol definitions from an established sources directly into their application codebases, and not repeatedly rewriting this functionality or relying on bindings to C\Java libraries. > Common Lisp was built to be an industrial-strength language I am not discussing the limitations of Common Lisp in particular, I am discussing the limitations of Lisp family of languages as a whole, and describing why there will most likely always be someone implementing a new slightly different variants of it, of which Common Lisp is but one example, and why it is unlikely that Lisp programmers will ever converge on one single language.