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