Hello, as others pointed out, a possibility is to use an interpreter. Maybe it's not what the original author wanted - execution speed may be a problem - but definitely possible.
The interpreter https://github.com/cosmos72/gomacro is fairly complete (some features are still missing, for example declaring new interfaces) and could fullfill such role. Disclaimer: I am the author. Also, the same interpreter exploits the generate-source-code + compile-and-load-plugin technique to implement "import" of non-standard packages, so this other technique is definitely feasible too. But it will not scale much: each compiled plugin contains all its dependencies, thus compiling and loading a new plugin for each small snippet of code generated at runtime will very quickly consume a lot of RAM. Regards, Max On Thursday, May 11, 2017 at 12:19:51 AM UTC+2, Erwin Driessens wrote: > > You could let your application generate valid Go source, call the compiler > to build a plugin, and load that plugin. I haven't tried that yet, but i > think it should work. Downside is that you need to Go tools on the target > machine for it to work. I don't know how many times you have to generate > new functions, the plugin system can't unload a plugin, so things might not > go so smoothly when you need to do this a lot of times in a single run of > the program. > > > On Friday, August 30, 2013 at 10:21:18 PM UTC+2, jzs wrote: >> >> Hi gophers, >> >> I was studying runtime code generation and was wondering if there's a way >> to generate a function at runtime. >> >> Let's say we have a function: fun(a,b) {return a+b} >> >> This function is parsed to our program as a string, parsed and compiled >> to a function in go. >> >> In C# and java you can do this as you have access to the clr and jvm >> which can jit compile your function for you. >> >> Now go is a statically compiled language and as far as I can see the >> reflect package is not powerful enough for such operations. >> >> Are my assumptions correct that this is not currently possible? >> Could it be done through cgo? (If yes a hint to c documentation would be >> nice :) ) >> Would it be possible in go in the future? >> >> Creative ideas are welcome but prefer portable solutions so no assembly >> generation through c or such :) >> >> For performance reasons it wouldn't be beneficial to have a. Net runtime >> running that you sent a million requests to. >> >> Kind regards, >> Jzs. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
