Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: read eval print loop facilities #39165
Many languages offer read eval print loops (REPLs) that allow interactive development of computer programs. REPLs are useful and timeless, and Go should have one.
Go has survived without a REPL, perhaps because compilation speed has always been a project priority. Often full, repeated re-compilation and -execution is a good substitute for a REPL, but there are advantages to working with a runtime:
The proposal is simple, perhaps too simple: REPLs are great, and go should have one. If a broad proposal is insufficient, I can attempt to work out more detail.
A brief note on my exploration so far:
One approach would be to extend the features of the plugin system to allow incremental definition of packages. The finality of a package is where I have struggled in implementing a REPL based on existing facilities: new methods cannot be defined, references cannot be made to unexported variables, and so forth. Could the plugin system allow a new version of a package to be installed that references existing internal package variables, functions, and types? Perhaps with restrictions, such as no replacement of existing functions, and packages that can be replaced need to be compiled with a special flag.
Without the ability to modify an existing package, it's already possible to use the plugin system to write a kind of go shell. For example, variables defined at top level can be put into a shell-managed package and referenced by manipulation of identifiers in the ast read by the shell. But this is all a bit clunky and limited. What we really want is to write a package like normal and add pieces of the package to the runtime as they are ready.
(I am not so concerned about supporting the deletion of a package or aspects of a package, but other languages do support such deletions at runtime with various limitations.)
Thanks. My experience with a repl is in Common Lisp (SBCL) where code is compiled and evaluated. The REPL solutions I have seen for Go seem to require writing an interpreter, not using the usual compilation pathway. Without compilation, the repl code can be slower, differ in subtle ways from compiled code, and overall feel second class.
The technical heart of the proposal, which is only implied at the moment, is being able to append to or replace parts of an existing package in a runtime.
Are you referring to re-running the full executable? I mention in the original post why this may be inadequate for certain workflows - workflows that are common practice in other languages. Perhaps you are referring to something else.