Eval piece of code stored in DB as string

I'm moving part of my application from PHP to Go. I'm storing some pieces of code to eval in MySQL, for example: checkGeo('{geo:["DE","AU","NL"]}') && check0s('{os:["android"]}'). In PHP it is easy, just eval($stringToEval), but how can this be done in Go lang?

In an interpreted language like PHP, implementing eval is fairly simple. But Go is a compiled language. To implement eval in Go would require writing an interpreter for Go. This would not be impossible, but it would be a big job.

-Edit<br />
You can have a look at https://godoc.org/bitbucket.org/binet/go-eval/pkg/eval which might do what you want. If it doesn't you could then maybe expand on it a bit. It isn't a full interpreter though.

Based on the examples you gave it seems like it'd be trivial-ish to build a bit of go code that knows how to evaluate checkGeo() or checkOs() rules; I think that'd be the best approach.

But that's not what you asked...

Another option would be to write the rules in Lua and run them with https://github.com/aarzilli/golua or in Javascript and use https://github.com/robertkrimen/otto

You don't need to pull in a full-blown interpreter for this sort of thing: write a simple parser that would pull your script apart into the syntax tree, and then write code that would walk that tree and "evaluate" it. It's not really that hard for simplistic cases like yours. And of course, your syntax might be made way simpler than PHP's since you don't want the full power of PHP's evaluator.

One simple example is rpn, but you can go simpler and invent a way to store your queries in, say, JSON.

Also note that Go has a Go parser in the form of a Go package &mdash; go/parser so you can write your queries using (minimal) Go syntax, parse them with go/parser and only implement an evaluator which would walk the AST produced by the parser and calculate the result. But I think this would be an overengeneering, given the example you've provided.

And a minor nitpick: storing the code which is to be evaluated by a full-blown evaluator, like PHP, is dangerous: if someone somehow manages to inject a call to exec() or something like this in your table, the result will be suboptimal. So having a primitive parser/evaluator is an upside from the security standpoint as well.