4 ms·

> 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

by 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 zeveb 11y ago

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.