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.
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.
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.
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.
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..
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?
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
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.
33 comments
[ 0.19 ms ] story [ 95.3 ms ] thread"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.
the perfect zen...
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.
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.
I guess targeting assembly is way harder, you must deal with register allocation and other scary-sounding topics.
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.
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/
Other than that, this looks like a lot of fun :-)
[1] http://golang.org/pkg/go/ast/ [2] http://golang.org/pkg/go/printer/
https://github.com/bytbox/kakapo