Gisp: A Lisp that compiles to Go | Hacker News Reader

Gisp: A Lisp that compiles to Go

github.com

80 pointsjcla131 comments

If you are wanting a native dynamic scripting language for Go, goluago is coming along quite nicely (alpha version released at New Year):

https://github.com/akavel/goluago

I think if I wanted to implement a native Lisp interpreter/ bytecode compiler for Go, I would build on top of this project rather than starting from scratch.

That looks useful, thanks.

For any programming language or platform without macros, a Lisp frontend appears.

A new law?

No, an old law.

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Since the quote is from 1993, you just need to replace C and Fortran by the languages of the day.

That's about the evolution of complicated programs, so quite different.

You'd be surprised how many language runtimes are complicated programs written in C....

But putting an s-expression front end on the language doesn't do anything to escape Greenspun, does it? Two different phenomena.

Nisp: A Lisp that compiles to Nothing

the perfect zen...

And if you need a Lisp that is nothing : https://en.wikipedia.org/wiki/NIL_(programming_language)

The perfect language for my NISC architecture for hardware. (Null Instruction Set Computer) My architecture is revolutionary, in that you can shrink die sizes and increase clock frequencies without limit, or eliminate the clock entirely, with zero impact on functionality and reliability. It is also an architecture to which the Halting Problem does not apply! This is huge, because all proofs of program correctness on NISC systems can be automatically evaluated in O(1) time and space.

For those playing with this type of code generation, you get to learn more by targeting Assembly instead.

Define a proper interface between ASTs and code generation and retarding the compiler is also not that complicated.

Or generate LLVM bitcode and use the LLVM tools to compile it to native.

Way better than relying in other compiler stacks.

Of course, it is a matter how deep one wants to get into compiler stuff.

s/retarding/retargeting/? Or something else? I haven't been able to come up with an interpretation where "retarding" makes sense in that sentence, but of course I'm not a native speaker.

I guess targeting assembly is way harder, you must deal with register allocation and other scary-sounding topics.

> s/retarding/retargeting/?

Ooops, a typo.

> I guess targeting assembly is way harder, you must deal with register allocation and other scary-sounding topics.

Not necessarily, if you are ok with just getting something to run.

You can pre-define a set of generation templates for each AST node, no need for register allocation.

See also Kakapo, an effort at a lisp interpreter in Go.

https://github.com/bytbox/kakapo

Author here, in case anyone has any questions!

How does it actually work? Does it compile to Go's intermediate language and then use the normal Go tool chain to compile it into native code, and then execute it? Or is it just an AST interpreter?

It takes a given Gisp program and then lexes/parses it into a Gisp AST. Then it translates that Gisp AST into a Go AST [1] and then just prints out [2] the Go program that would generate that specific Go AST.

[1] http://golang.org/pkg/go/ast/ [2] http://golang.org/pkg/go/printer/

Does look like it could use a little more documentation? Am I missing something or is the only list of supported syntax etc the (very limited) examples and the implementation itself? There's no design/goal document listing what's supported or not?

Other than that, this looks like a lot of fun :-)

Indeed it was a lot of fun implementing it (author here), and yes it could do with some more documentation, though up to now no one besides me was really concerned about the functionality... :-0

Feels like this is the beginning of a trend: Clojure, Hy and now Gisp.

This has always been done. Very view of these will actually get any real world use.

Traditionally C was the target language, many Schemes compile to it with great results. Writing a Lisp on top of something else has a very long tradition and certainly is not beginning just now. :)

What interests me is can these Lisp implementations facilitate easier translation between languages, e.g. write in Python, Python translated to Hy, Hy translated to Gisp, Gisp translated to Go. Whilst lisp dialects do differ, I'd imagine such links would be easier than a direct Python to Go translator.

Kind of - although these are all 'lisps', there's quite a lot of difference between them all. Most of these are keeping with their 'host' language scoping rules, for instance. Also external library calls, etc.

but the main reason to use these language-hosted lisps rather than just using one of the mainstream lisps is to get access to the host language's libraries and ecosystem. that wouldn't translate particularly well between languages.

This exactly my thought too. It looks like everybody who already know Lisp will developed some sweet spots for it. My guess once you experience the Lisp kool-aid, it'll be hard to be apart with it. You'll miss it whenever you code.

Is there a Scheme implementation that compiles to Go?

I haven't seen that yet, could be a fun thing to have. I just found an implementation of Tinylisp in go. It would be fun to have all the funky goroutines in a schemish design..

http://www.oki-osk.jp/esc/golang/lisp.html

On another note, there is Chicken Scheme, which compiles to C and produces executable files. Nice stuff!

www.call-cc.org/‎

There are lots of them that compile to native code.

Oh my god, if someone wrote a bitcoin wallet that protected you chats from the NSA in this List that compiles to GO THIS WOULD BE THE PERFECT HN POST.

Reply on news.ycombinator.com