env[] keyword implemented in parser

[mdmcconnell]

The env[] keyword allows an expression to access identifiers in env directly, with any name desired, including numbers, spaces, special characters, etc. Syntax env['string identifier'] and env["string identifier"] are allowable, as is any index that evaluates to a string.

[antonmedv]

What about this case?

env[anotherVar]

[mdmcconnell]

I think you are asking "what if the env[] index is an identifier, not a string?". Previously, we had dicussed along the lines of "env[] index must be a string", but allowing an identifier that evaluates to a string seems reasonable, if more complex. I will look at that.

[antonmedv]

Also what about env[“foo” + “bar”]?

[mdmcconnell]

That is another case of "something that evaluates to a string", versus "a string" which I had intended. env[strfun(stuff)] would be another example, etc. It's not the original idea, but I think a reasonable expectation. I will have to implement further "downstream" in expr execution.

[mdmcconnell]

Back to this - have now implemented so that any index that evaluates to a string. I had to add a new opcode, since evaluation of the index may not happen until running the expression. This will not be backwarsd compatible with expressions that have a an array or map named "env" in their environment; I think that is common with expr keywords - I can not for example define a function named "len".

[antonmedv]

Overall a good PR. Much simple implementation. 👍🏻

[antonmedv]

Nice work! 🎉

[antonmedv]

Completely forgot. Please, write documentation for this feature. Thanks!

[mdmcconnell]

Yes, of course - will write some documentation hopefully before next week. Thank you for your patience while I've been learning how expr package works!

[antonmedv]

Also: will be nice to add this to expr/docgen

[harkli]

The env[] keyword allows an expression to access identifiers in env directly, with any name desired, including numbers, spaces, special characters, etc. Syntax env['string identifier'] and env["string identifier"] are allowable, as is any index that evaluates to a string.

env["env"] will cause panic: attempt to misuse env keyword as env map key

func TestEnv(t *testing.T) {
env := map[string]interface{}{
"env": "demo",// panic!!!
}
p, e := expr.Compile(env == "demo", expr.Env(env))
o, e := expr.Run(p, env)
fmt.Println(o)
fmt.Println(e)
}

[mdmcconnell]

That is WAD - it's not allowed to call any variable "env" (or other identifier) because the behaviour becomes indeterminate. Which should have precedence, the keyword or the user-defined variable? Should env[] recursively map into itself? There is some discussion above around 9-Jul. At the moment, other keywords like "len" can be overloaded, and there is intention to disallow that as well.