Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

uLisp – Lisp for the Arduino

ulisp.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: uLisp – Lisp for the Arduino

#11

Post by Steltek »

AceJohnny2 wrote: post #3

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?

> 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.

Re: uLisp – Lisp for the Arduino

#12

Post by WillPostForFood »

nice_byte wrote: post #2

> It's also an ideal language for expressing complex ideas, such as [...] finding the shortest route on a map So, I googled "Dijkstra's Algorithm in Lisp" and got this: http://richardsherriff.com/?p=233 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…

There are better comparisons here. The Lisp version is pretty nice compared to most of the imperative versions:

http://rosettacode.org/wiki/Dijkstra%27s_algorithm

Re: uLisp – Lisp for the Arduino

#13

Post by askvictor »

WillPostForFood wrote: post #6

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?

Check out esp8266/nodemcu. They can be programmed in lua or micropython (or arduino ide). Not as much of an ecosystem/community, but growing. Includes wifi on-chip, and dirt cheap.

Re: uLisp – Lisp for the Arduino

#14

Post by lispm »

Steltek wrote: post #11
AceJohnny2 wrote: post #3

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?

> 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.

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

Re: uLisp – Lisp for the Arduino

#15

Post by DigitalJack »

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.

That said, I just don't get statements like:

"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.

Re: uLisp – Lisp for the Arduino

#16

Post by Volt »

nice_byte wrote: post #2

> It's also an ideal language for expressing complex ideas, such as [...] finding the shortest route on a map So, I googled "Dijkstra's Algorithm in Lisp" and got this: http://richardsherriff.com/?p=233 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…

>in an imperative language

Lisp is capable of imperative programming.

Re: uLisp – Lisp for the Arduino

#17

Post by e12e »

nice_byte wrote: post #2

> It's also an ideal language for expressing complex ideas, such as [...] finding the shortest route on a map So, I googled "Dijkstra's Algorithm in Lisp" and got this: http://richardsherriff.com/?p=233 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…

You might want to look at something like:

https://github.com/gwkkwg/cl-graph/blob/master/dev/graph-alg...

or perhaps: https://planet.racket-lang.org/package-source/jaymccarthy/di...

I was a little surprised to not find any direct graph algorithms at rosetta code[1], but for showing off somewhat similar code, this might be of interest:

http://rosettacode.org/wiki/Longest_common_subsequence#Commo...

I don't really think common lisp is a great beginning language, compared to, say, python or ruby - although Racket Scheme is pretty nice. I did for example come across this introduction to A * that uses Python for the code examples:

http://www.redblobgames.com/pathfinding/a-star/introduction....

As for introduction to new programmers, Racket's tutorial is kind of nice, jumping right in to do some simple graphics with an embedded DSL:

https://docs.racket-lang.org/quick/

[1] WillPostForFood obviously out-searched me here, finding: http://rosettacode.org/wiki/Dijkstra%27s_algorithm Not sure how I managed to not find it - perhaps trusting search rather than trying to use the site-index would've helped...

Re: uLisp – Lisp for the Arduino

#18

Post by pcl »

Varriount wrote: post #10
pcl wrote: post #7

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 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…

As I said in another thread recently, garbage collectors don't have to be of the stop-the-world, non-deterministic kind. It's perfectly possible to have real-time garbage collection [1], and the language I commonly work with supports soft real-time use with the default GC [2]. I'm no expert on garbage collection techniques, but what I have picked up is that most of the challenge lies in timing of the collections (whe…

Yes, but the language chosen implied to me that it's using a stop-the-world approach.

I've confirmed this by looking at the (surprisingly readable and small) code: http://www.ulisp.com/list?1BWZ

Also, it looks like the algorithm is mostly deterministic, so that's good from a real-time standpoint. And it only runs if memory is about to be exhausted, so if the application ensured that it stayed within the Arduino's memory budget, it's essentially a no-op.

Re: uLisp – Lisp for the Arduino

#19

Post by cscurmudgeon »

nice_byte wrote: post #2

> It's also an ideal language for expressing complex ideas, such as [...] finding the shortest route on a map So, I googled "Dijkstra's Algorithm in Lisp" and got this: http://richardsherriff.com/?p=233 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…

1. Find bad possibly code written in a language (by possibly a starting student).

2. Use it to invalidate any arbitrary claim X about the language.

3. Profit?

Re: uLisp – Lisp for the Arduino

#20

Post by sigil »

This looks really neat! There was a story about Lisp at JPL that got me dreaming about embedded REPLs:

> 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.) http://www.flownet.com/gat/jpl-lisp.html

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.

Post reply on HN