4 ms·

> A key feature of lisp of that code IS data. I think this is an oversimplification. "Code is data" means several things: 1. Both use the same ASCII represen

by Steltek 10y ago

> A key feature of lisp of that code IS data. I think this is an oversimplification. "Code is data" means several things: 1. Both use the same ASCII representation to humans (homoiconity) 2. Lisp Macros operate using data traversal functions 3. You can load and eval code on the fly Really only #3 is invalidated under Arduino constraints. #1 is the source at rest and #2 is compile-time.

lispm 10y ago
ulisp can load and evaluate Lisp code on the fly on the arduino.
TeMPOraL 10y ago
3. is not invalidated under Arduino in a general sense. The split into "code memory" and "data memory" is only relevant to the meaning of "code" and "data" assigned by uC-level assembly. There's nothing stopping your code to reinterpret data as code. Consider: that's how interpreters and VMs are made :). Moreover, 1-3 together are more than sum of its parts. The idea that "in Lisp code = data" doesn't mean that elsewhere it doesn't; code = data is a fundamental truth about the nature of information (that many other languages and their ecosystems did quite a lot of work to obscure). Lisp only makes exploiting that truth much easier than other languages. Also, a nitpick. #2 is not "compile-time". Macros can and are expanded at what you'd call "run-time" as well. Generally, Lisp systems don't have "compile-time" and "run-time" you know from other languages; the split is usually read- / load- / compile- / run-time, with some other "times" sprinkled in (e.g. "macroexpansion-time"), and this split is not necessarily sequential - you can read/load/compile stuff in what would usually be called "runtime", and read/load/compile phases have full access to features of the running Lisp image, including changes you made previously - so, for example, code you're just compiling can, during its read-time, refer to variables you previously created at run-time and run computations on them.

by Steltek 10y ago

lispm 10y ago

ulisp can load and evaluate Lisp code on the fly on the arduino.

TeMPOraL 10y ago

3. is not invalidated under Arduino in a general sense. The split into "code memory" and "data memory" is only relevant to the meaning of "code" and "data" assigned by uC-level assembly. There's nothing stopping your code to reinterpret data as code. Consider: that's how interpreters and VMs are made :). Moreover, 1-3 together are more than sum of its parts. The idea that "in Lisp code = data" doesn't mean that elsewhere it doesn't; code = data is a fundamental truth about the nature of information (that many other languages and their ecosystems did quite a lot of work to obscure). Lisp only makes exploiting that truth much easier than other languages. Also, a nitpick. #2 is not "compile-time". Macros can and are expanded at what you'd call "run-time" as well. Generally, Lisp systems don't have "compile-time" and "run-time" you know from other languages; the split is usually read- / load- / compile- / run-time, with some other "times" sprinkled in (e.g. "macroexpansion-time"), and this split is not necessarily sequential - you can read/load/compile stuff in what would usually be called "runtime", and read/load/compile phases have full access to features of the running Lisp image, including changes you made previously - so, for example, code you're just compiling can, during its read-time, refer to variables you previously created at run-time and run computations on them.