From playing with it a little, 1) I dig it and not unlikely I'll use it in some situations I'd otherwise hit the Playground for, 2) here, of course, are some ideas:
- Running bradfitz/goimports (if it's in the $PATH) on the session file before executing it and picking up any imports it adds. So f, err := os.Open("foo") would work without me explicitly :import'ing os.
- Enabling gocode autocompletion after you type :doc, and possibly stripping a trailing '('. This'd be a cheat to let you type :doc fmt.P[tab] enter.
- Hiding __gore_p from the written/printed output. Possible there's a technical reason that's less of a good idea than it sounds like.
- :read to load a session, and/or similar shortcuts to save you from retyping the same inputs to set up the environment -- e.g., taking a session filename on the command line and defaulting to ~/.gorerc if it exists.
- :play -- submit some version of the session file to the Go Playground and print the URL (for sharing, say). The Playground's "About" link says automatic use is OK if you're cool about it (and has a more complete definition of "if you're cool about it").
Thanks for the work and don't let the spew of ideas distract from that I like what you've got and find it useful.
Also, I feel sort of annoyed at myself for even having replied like that to a useful tool. :P Forget all that I wrote up there, and good work, author, should you ever read this.
I feel there should be a different word available for a REPL that you can call out into from your own code, where the REPL has access to the lexical scope at the point of the call. Like binding.pry in Ruby, or 'debugger' in Javascript.
A REPL that doesn't let me break out with current lexical scope only gives me 10% of what I use a REPL for. Without that feature, they're of limited use; more suited to playing with a language than productively writing and debugging code.
No, a debugger is something that supports, at a minimum, breakpoints, stepping and memory inspection.
Many debuggers - if not most - do not support arbitrary constructs in the language being debugged. They don't normally support creating new variables (by which I explicitly do not mean a name for an expression). And they very rarely support writing new or overwriting existing functions.
When I use pry, it's normally as a REPL with scope bindings, not as a debugger. That is, I don't use it for breakpoints or stepping. I use it to write code in the context of where the code is going to live. When I need to modify a Ruby method, I stick a binding.pry in it, then write the new code iteratively in the console in the context of a test or seed data, and copy and paste finished code into an editor when I'm happy with the results.
A REPL that only supports creating new definitions is simply not very useful to me. It doesn't support what I use REPLs for. They're mostly just toys - IMO.
- Running bradfitz/goimports (if it's in the $PATH) on the session file before executing it and picking up any imports it adds. So f, err := os.Open("foo") would work without me explicitly :import'ing os.
- Enabling gocode autocompletion after you type :doc, and possibly stripping a trailing '('. This'd be a cheat to let you type :doc fmt.P[tab] enter.
- Hiding __gore_p from the written/printed output. Possible there's a technical reason that's less of a good idea than it sounds like.
- :read to load a session, and/or similar shortcuts to save you from retyping the same inputs to set up the environment -- e.g., taking a session filename on the command line and defaulting to ~/.gorerc if it exists.
- :play -- submit some version of the session file to the Go Playground and print the URL (for sharing, say). The Playground's "About" link says automatic use is OK if you're cool about it (and has a more complete definition of "if you're cool about it").
Thanks for the work and don't let the spew of ideas distract from that I like what you've got and find it useful.