sbinet
Bump!
Hey,... it'd be so great to have a Go interpreter! Embedded in Go, ..
It'd be like that: https://www.youtube.com/watch?v=9CS7j5I6aOc
So, anyone working on this ?
still interested in having a go interpreter. actually, a few months ago, I teamed up with Elliott (@elliott5) to draw some plans and try to accrete a critical mass: https://docs.google.com/document/d/1Hvxf6NMPaCUd-1iqm_968SuHN1Vf8dLZQyHjvPyVE0Q/edit https://groups.google.com/forum/#!msg/golang-nuts/BVxEW6MHY3c/56Z1J1ao4TsJ
Yes, I'm still keen too, even if I've not been saying much lately!
Before I started my new job a few months ago, I'd been extending and speeding-up the ssa interpreter originally written by Alan Donovan. The work-in-progress is at https://github.com/tardisgo/tardisgo-samples/tree/master/wip/ssainterp - the ssainterp.go program is just me messing around really, but the extended tests in the interp directory all pass.
@sbinet would you like me to get it into a more presentable form in its own repo named say "ssainterp" and put it (as a work-in-progress) in the go-interpreter organization?
Also you won't be surprised to know that I've been thinking further about how to persist heap data between REPL invocations, but I've yet to crystalize my thoughts by writing them down.
There is a development of Alan Donovan's work at https://github.com/go-interpreter/ssainterp which @glycerine kindly upgraded to work with Go1.7. You could also contribute to the many ideas on how to develop an interpreter at https://github.com/go-interpreter/proposal - please add your thoughts.
and I have started some more detailed leg work wrt bytecodes and VMs here:
- https://sbinet.github.io/posts/2016-09-07-start-interpreter/
- https://sbinet.github.io/posts/2016-09-09-tiny-interpreter/
Rob Pike's talk on "The Design of the Go Assembler" made it seem like the byte code we are looking for was already designed by Ken Thompson, and the go compile tool already produces it. https://www.youtube.com/watch?v=KINIAgRpkDA
