Writing a Lisp Interpreter in Go | Hacker News Reader

Writing a Lisp Interpreter in Go

bobappleyard.wordpress.com

34 pointsfogus10 comments

Curious. It implies tail call elimination (the description of exhausting the stack explicitly says it wasn't a tail recursive call), but the description sounds like it's so direct that I can't see how it works.

Looking at evalExpr - http://github.com/bobappleyard/golisp/blob/master/lisp/lisp.... - the only way I can see for this to have tail call elimination is if Go itself does (and I don't think it does, does it? It does have coroutines, which you could use to implement trampolining, but I don't see that here...)

I think tail call elimination is handled in the Apply method for closures - http://github.com/bobappleyard/golisp/blob/master/lisp/lisp.... . Looks like a trampoline to me.

Ahhh. Thanks. After thinking about that I realised I don't understand Go's syntax :o)

I wrote a quip awhile back about wanting a scripting language closely integrated with Go. Maybe this would fit the bill? (Though one with a Go-like syntax would be better.)

That somewhat points to a development environment that I would like---a statically compiled language that is also easily interpreted. You develop with the interpreted version to get the quickest turnaround, and then you compile it for speed when you're ready to release your product.

Seems like LLVM or the JVM would both make this comfortable.

You should check out Groovy then. It has optional typing. Put in enough type annotations, and it's compiled Java.

Can't but wait for go interpreter in lisp :)

One that can compile its Lisp programs into Go.

Now he can program in a proper language.

Obligatory mention of having to use Readability for light-on-dark text...

EDIT: Some of us are on the other side of 30 and won't waste our eyesight on a blog by someone who thought white-on-black was kewl. Those under 30 shouldn't, either.

Reply on news.ycombinator.com