4 ms·

The AVR cpu at the core of the Arduino uses a (modified) Harvard architecture., which separates code from data memory. A key feature of lisp of that code IS dat

The AVR cpu at the core of the Arduino uses a (modified) Harvard architecture., which separates code from data memory. A key feature of lisp of that code IS data. How does uLisp bridge the contradiction?

lispm 10y ago
It provides a Lisp interpreter written in C. You can read the implementation... code: http://www.ulisp.com/list?1BWZ http://www.ulisp.com/list?1BWZ
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.
TeMPOraL 10y ago
Code IS data, that's a fundamental fact of reality, and not something mere chip architecture can invalidate. Separating "code memory from "data memory" only means you can't have bits from "data memory" flowing directly into the chip to be run. It doesn't prevent you from having some code in "code memory" that would translate the data into code, by e.g. means of flow control.

lispm 10y ago

It provides a Lisp interpreter written in C. You can read the implementation... code: http://www.ulisp.com/list?1BWZ http://www.ulisp.com/list?1BWZ

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.

TeMPOraL 10y ago

Code IS data, that's a fundamental fact of reality, and not something mere chip architecture can invalidate. Separating "code memory from "data memory" only means you can't have bits from "data memory" flowing directly into the chip to be run. It doesn't prevent you from having some code in "code memory" that would translate the data into code, by e.g. means of flow control.