Support for loading a file and opening a repl in its lexical scope

[Phil Hagelberg]

One thing that makes the repl significantly less useful is that the only way I can load a file into the repl and have access to its internal functions is by making them globals. So I'm forced to choose between convenience and correctness, or more often, I just delete the "local" before each definition before loading up the file. Obviously this is less-than-ideal.

What I would like to see is a feature that allows you to load up a file but run a repl inside the lexical scope of the file. Sort of like if you replaced the final return of the file with debug.debug(), except debug.debug doesn't actually honor lexical scope, so it's kinda useless.

Is there a better way to do this that already exists? I have a hard time believing that there's no way to do this yet, but I haven't found anything that supports convenient repl programming yet, though of course this project is a huge improvement over the hilairously-crippled repl that ships with stock lua.

[Rob Hoelz]

@technomancy I like the idea; how are you thinking it should work? Something like rep.lua -lfile_im_working_on.lua, or dropping something like repl.run_here() into file_im_working_on.lua?

[Phil Hagelberg]

Yeah, basically. Ideally you'd be able to change the current file without restarting the repl and losing your state though. I do something similar here where you can load all the required libs for a given file and use it to source completions: https://github.com/immerrr/lua-mode/pull/119/files In that case it's left off by default because it could trigger side-effects that would be surprising for completion, but I don't think that's such an issue with a repl. I feel like without this, you can only test an exposed API interactively; it's very tedious to test internal functions, which has the unfortunate effect of encouraging you to make more functions public than you otherwise would.

[Rob Hoelz]

@technomancy Interesting idea - do you know of other REPLs that do this that I could use as an example for the behavior?

[Rob Hoelz]

@technomancy Something like enter! in Racket, perhaps?

[Phil Hagelberg]

Yeah, there are many other repls that give this feeling; Racket, as you've noted, Clojure, and Common Lisp. However, these are all differ in that they have some runtime construct of a module, package, or namespace as something more than just a data structure that contains functions and other values. In Lua, the idea of the "current module" refers to a concept that more or less evaporates at runtime; at runtime all that's left is the table that's returned by the module, and the local scope of the file disappears. These languages do not depend entirely on lexical scope for values internal to the module like Lua does. The only other language I know which does work this way is OCaml, and as far as I remember, it has a similar problem with the repl. Though it's not as bad in OCaml because the scope introduced when you type the equivalent of "local x = 2" remains around for future expressions. If there were a way to get that kind of behavior it would solve the same problem, but I get the feeling that kind of thing can't really be fixed outside the core language. I suppose the root of this problem is that each chunk of user-input code is running in a lexical environment that is isolated from the next.

[Rob Hoelz]

Something to think about regarding this idea; let's say you have the following module:

local count = 1
local function incr()
  count = count + 1
  return count - 1
end

return { incr = incr }

What should happen if you're using the REPL in this module, you change incr and reload the module? Should count reset to zero? Should we try to preserve its value?

[Phil Hagelberg]

Languages like Clojure and Elisp have a special "defonce" construct for this exact reason. Personally I think I would rather have it reset to the initial value upon every load. I could see that causing problems with some workflows, but I have a suspicion those workflows are a lost cause for interactive development anyway.

[Rob Hoelz]

Ok, thanks for the input!

[Rob Hoelz]

Somewhat related to #28