evalexpr
evalexpr copied to clipboard
ISibboI
Possible logic within expressions?
Is it possible to insert logic into expressions?
expr = "true ? 1 : 0"
or
expr = "if true { 1 } else { 0 }"
At the moment that is not possible the way you wrote it.
Albeit as a hack, you can add a function if to your context, that has three arguments. First is a condition (boolean), and if it is true, the function returns the second argument, otherwise the third.
I plan on adding some basic control flow features like branches and loops at some point, but did not get around that yet.
Sure. If it is something bigger, we might want to discuss it first though.
On Sun, Jun 13, 2021 at 7:00 PM Jacob LeCoq @.***> wrote:
Are you accepting PRs for enhancements?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ISibboI/evalexpr/issues/82#issuecomment-860233551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASATXXBMNL374WYHDQL4SLTSTIYHANCNFSM46S2CI3Q .
keep in mind that depending on the kind of control-flow support this introduces a new class of security issues in form of infinite loops.
@ISibboI I am planning to implement expr = "true ? 1 : 0" conditional expression. Do you have any suggestions?
Personally, I'm perfectly fine with the if function hack. It allows to keep the syntax simple and uniform. Also, I'm not a big fan of the ternary operator, even after coding in C for many years.
@ISibboI I am planning to implement
expr = "true ? 1 : 0"conditional expression. Do you have any suggestions?
I am not an expert in software engineering, but I trust the rust people in that the ternary operator is "bad". So I would like to avoid it. Also to keep this crate's syntax close to that of Rust.
I would be fine with an actual if <expression> {<expression>} [ else {<expression>}] syntax. I think that the current parser is not really made for this kind of syntax though, and it would likely be necessary to build a recursive descent parser around the current one for these expressions that are not "arithmetic" expressions.
I had the thought in the past to extend this crate into a little interpreted language like this, but I am not so sure. It would introduce a lot of extra code that is not necessary for the original goal of evaluating arithmetic expressions, or simple string expressions like you would use for game engines or config files.
But well, there would still be options to go about this, like making a separate crate that handles the control flow expressions, and then uses evalexpr to handle arithmetics and so on. But then again, having an interpreter split into two separate libraries like this may also have disadvantages that I don't see. I am not really sure what is best to do here.
Considering that users can make if function like as you said, it's probably better without if expression.