3 ms·

BTW, there's a Lisp that compiles to Go AST, and then derives Go code from that. (Won't find it right now, though.)

by aasasd 7y ago

codr7 7y ago
I've been considering compiling the interpreter as a shortcut to native executables, but to Go rather than its AST since that allows reusing the existing runtime. The main idea behind G-Fu is to complement Go by providing a more expressive experience while delegating the heavy-lifting. Which means that performance is far from the top priority.
- aasasd 7y ago
  There's an approach to compilation where you take the input program, but instead of running it you output what the interpreter would do, as a new program. So you get meh performance but you have an executable. Here's a project doing that: https://news.ycombinator.com/item?id=19508616 https://news.ycombinator.com/item?id=19508616 This is a theory around this approach: https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
  - codr7 7y ago
    Yep yep, we're talking about the same thing. I like to call it an inline interpreter. It's a nice compromise. The emit-logic can be kept fairly uniform and low-maintenance since its more or less identical to the regular interpreter. I got around 10% increased performance on a Forth in C for whatever that's worth. One thing to keep in mind is to use functions in the emitted code rather than simply dumping everything in a pile. Most compilers don't deal well with code piles from my experience , which makes the code both compile and run slower than it could.
aasasd 7y ago
Here it is, I think: https://github.com/jcla1/gisp https://github.com/jcla1/gisp
- codr7 7y ago
  Thanks. It's very shallow though, more demo toy than practical tool like most Lisps.
  - JasonFruit 7y ago
    I'm not sure if you mean, "Like most Lisps, it's more demo toy than practical tool," or, "Unlike most Lisps, it's more demo toy than practical tool." Depending on whether by "most Lisps" you mean most established Lisps or the numerical majority of Lisp implementations, I could see either reading, and your punctuation doesn't make it clear. There are a lot of zero-user toy Lisps out there.
    - codr7 7y ago
      That was my point, most of them aren't even trying. And the posted link seems to be one of those. Just wanted to note that its not really comparable to what g-fu is doing.

BTW, there's a Lisp that compiles to Go AST, and then derives Go code from that. (Won't find it right now, though.)

by aasasd 7y ago

BTW, there's a Lisp that compiles to Go AST, and then derives Go code from that. (Won't find it right now, though.)

I've been considering compiling the interpreter as a shortcut to native executables, but to Go rather than its AST since that allows reusing the existing runtime. The main idea behind G-Fu is to complement Go by providing a more expressive experience while delegating the heavy-lifting. Which means that performance is far from the top priority.

aasasd 7y ago
There's an approach to compilation where you take the input program, but instead of running it you output what the interpreter would do, as a new program. So you get meh performance but you have an executable. Here's a project doing that: https://news.ycombinator.com/item?id=19508616 https://news.ycombinator.com/item?id=19508616 This is a theory around this approach: https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
- codr7 7y ago
  Yep yep, we're talking about the same thing. I like to call it an inline interpreter. It's a nice compromise. The emit-logic can be kept fairly uniform and low-maintenance since its more or less identical to the regular interpreter. I got around 10% increased performance on a Forth in C for whatever that's worth. One thing to keep in mind is to use functions in the emitted code rather than simply dumping everything in a pile. Most compilers don't deal well with code piles from my experience , which makes the code both compile and run slower than it could.

aasasd 7y ago

Here it is, I think: https://github.com/jcla1/gisp https://github.com/jcla1/gisp

codr7 7y ago
Thanks. It's very shallow though, more demo toy than practical tool like most Lisps.
- JasonFruit 7y ago
  I'm not sure if you mean, "Like most Lisps, it's more demo toy than practical tool," or, "Unlike most Lisps, it's more demo toy than practical tool." Depending on whether by "most Lisps" you mean most established Lisps or the numerical majority of Lisp implementations, I could see either reading, and your punctuation doesn't make it clear. There are a lot of zero-user toy Lisps out there.
  - codr7 7y ago
    That was my point, most of them aren't even trying. And the posted link seems to be one of those. Just wanted to note that its not really comparable to what g-fu is doing.