|
|
|
|
|
by sbinet
3557 days ago
|
|
I beg to differ.
See: https://github.com/sbinet/igo It is a true REPL (not like "gore", mentioned somewhere in that thread).
It doesn't implement the whole Go specs, but there's AFAICT nothing in the Go specs that prevent `igo` to implement the whole Go specs.
It's "just" work.
Moreover, with the introduction of the "buildmode=plugin" in the yet-to-be-released Go-1.8, import-ing packages on the fly should be easy implementable. ("my" new vehicle to provide a true REPL for Go is at https://github.com/go-interpreter) |
|
Further, I'd suggest waiting for one of these projects to complete before you confidently declare that the REPL will be great. I didn't say it's impossible, I said "it's always going to be limited compared to a language that was designed to do it". I looked into what it would take to make a REPL around the Go 1.2 timeframe. There are many issues, such as the inability to query a package for what symbols it has, or the way the obvious workarounds have their own problems, brought on for instance by the fact that you can't re-export symbols in another package so the whole "just keep compiling a module incrementally" has its own issues. At this point I'm pretty confident that the best reasonably-possible Go REPL (i.e., not one that basically reimplements Go again) is going to come with a list of caveats a mile long. And if you do reimplement Go for the REPL, which a SSA interpreter basically is, you don't really have a Go REPL... you have a Go-like REPL at best.