This looks really neat! There was a story about Lisp at JPL that got me dreaming about embedded REPLs:<p><i>> The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.)</i>
<a href="http://www.flownet.com/gat/jpl-lisp.html" rel="nofollow">http://www.flownet.com/gat/jpl-lisp.html</a><p>So often in embedded development I resort to things that make printf-style debugging look downright virtuous. ("If you reach some complicated runtime state, blink the LED thrice.") Having a REPL would let you poke around without the compile-flash-test cycle and have an actual conversation with the hardware.
Though uLisp has tail-call optimization, if the C compiler doesn't, then the garbage collector needs stack in proportion to list length:<p><pre><code> void markobject (object *obj) {
if (obj == NULL) return;
object* arg = car(obj);
if (marked(obj)) return;
int type = obj->type;
mark(obj);
if (type != SYMBOL && type != NUMBER) { // cons
markobject(arg);
markobject(cdr(obj)); // <--- TAIL CALL!
}
}
</code></pre>
It's simple enough to obj = cdr(obj) and wrap a loop around this.
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?
> It's also an ideal language for expressing complex ideas, such as [...] finding the shortest route on a map<p>So, I googled "Dijkstra's Algorithm in Lisp" and got this: <a href="http://richardsherriff.com/?p=233" rel="nofollow">http://richardsherriff.com/?p=233</a><p>Now, I'm no lisp expert, so I can't judge whether the author of this code actually knows what they're doing, but I know for sure that in an imperative language the implementation of the algorithm is much more concise and understandable.<p>I have concluded from my observations that claims of Lisp being "easier", "ideal for learning fundamental programming concepts" and "more expressive" are exaggerated.
<i>uLisp includes a mark and sweep garbage collector. Garbage collection takes under 1 msec on an Arduino Uno or under 3 msec on an Arduino Mega 2560.</i><p>I wonder how predictable and controllable that is. Adding GC to what is likely to be a real-time device seems like a potential showstopper. But if the numbers can be a bit more firm, or if the application can receive alerts on pause / resume, that might not be such a big deal.
Lisp for Arduino sounds great. The C programming barrier has kept me from tinkering with Arduino. Does this give you access to arduino shields/expansion boards (wifi/gps/screens), or will that be dependent on device drivers?
Nice!
This reminds me of my tiny Lisp Machine project:
<a href="https://aaron-fischer.net/tdn" rel="nofollow">https://aaron-fischer.net/tdn</a>
<a href="https://translate.google.com/translate?hl=en&sl=de&tl=en&u=https%3A%2F%2Faaron-fischer.net%2Ftdn" rel="nofollow">https://translate.google.com/translate?hl=en&sl=de&tl=en&u=h...</a>
This reminds me of muLISP [0].<p>[0]: <a href="https://de.wikipedia.org/wiki/MuLISP" rel="nofollow">https://de.wikipedia.org/wiki/MuLISP</a>
Clojure is my favorite language, and I'd probably like scheme just as well if it had the easy to use (yet advanced) Data structures of clojure. I just can't seem to get my brain to mesh with Common Lisp yet, but I periodically dip my toes to test the water.<p>That said, I just don't get statements like:<p>"It's also an ideal language for expressing complex ideas, such as teaching a robot to solve mazes or finding the shortest route on a map." More ideal than C, sure. But I don't see the huge advantage over other high level languages.