[jerf]

If you have to link to a different project, then the link I was saying is not a REPL is not a REPL, no?

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.

[sbinet]

I was challenging your "Go is not set up to have a REPL" assertion. we are in violent agreement about the (non) "REPL-ness" of _gore_ and the fact that "just keep compiling a module incrementally" is a dead end.

I don't see how reimplementing Go in Go but with a REPL (on top of, let's say, a SSA interpreter) is a Go-like REPL at best and not just a Go REPL. Could you expand a bit?

AFAICT, once one has a Go interpreter (the x/go/ssa is basically just that), implementing a REPL is "just" providing a program counter to the interactive interpreter layer, together with the ability to modify that PC... (many details have been dropped on the floor, of course)