Feasiblity of a delve-style Go interpreter. #3692
Replies: 1 comment 1 reply
-
If you mean extend the expression interpreter of delve (i.e. the stuff in eval.go and evalop) so that it can handle arbitrary chunks of go code, that's no different than using yaegi: you'd be writing your own VM. Otherwise, delve can't generate it's own data types or compiled functions. What you could do is shell out to the go toolchain and use the plugin package to load stuff in. In fact, you don't even need to do it in delve, I'm pretty sure at some point there was a go repl that used a patched version of the toolchain to do this, or something similar (I suspect you'll have to use a patched version of the toolchain anyway, because of global variables). It shouldn't be too hard to do. The hard part is what to do when people start redefining either types or functions (but especially types). That's a general (serious) problem with repls, even existing ones, but it's especially evident with languages designed to be fast (as opposed to putting a couple of layers of indirection everywhere, like most repl-friendly languages do). |
Beta Was this translation helpful? Give feedback.
-
Context: Yaegi is a "Go interpreter" that uses
go/ast
to parse Go fragments, converts the Go AST to it's own internal representation, then executes it in a custom VM-like engine. However since Yaegi uses a custom engine, there are gaps - valid Go expressions that don't execute or execute incorrectly (differently from real Go).Delve has the ability to execute some kinds of Go. I'm wondering if it would be feasible for someone (e.g. me) to create something that would spawn a real Go process and use something like delve to dynamically generate data types and execute code, behaving like a Go interpreter/repl. Any idea how feasible that is on a scale from "I could do it in a weekend" to "Give me a quantum computer and century to research it"?
Beta Was this translation helpful? Give feedback.
All reactions