search

ISibboI / evalexpr

A powerful expression evaluation crate 🦀.
GNU Affero General Public License v3.0
320 stars 52 forks source link

Possible logic within expressions? #82

Open bayou-brogrammer opened 3 years ago

bayou-brogrammer commented 3 years ago

Is it possible to insert logic into expressions?

expr = "true ? 1 : 0" or expr = "if true { 1 } else { 0 }"

ISibboI commented 3 years ago

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.

bayou-brogrammer commented 3 years ago

Are you accepting PRs for enhancements?

ISibboI commented 3 years ago

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 .

M1cha commented 2 years ago

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.

hexofyore commented 1 year ago

@ISibboI I am planning to implement expr = "true ? 1 : 0" conditional expression. Do you have any suggestions?

dvtomas commented 1 year ago

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 commented 1 year ago

@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.

hexofyore commented 1 year ago

Considering that users can make if function like as you said, it's probably better without if expression.