yds12 / mexe Goto Github PK

Use perf or flamegraph or any other profiling methods such as the ones here to find what needs optimisation.

Run fuzzing test to catch possible bugs. We can use cargo-fuzz.

Although we have a minimal API, it's good to improve the crate-wide docs (//!), and also document the ancillary types (error types, etc).

Read and conform to the API guidelines.

Run tests on every push. Similar to what we have in guarakapa.

We are considering all numbers to be f64. Some users might want to calculate everything with integers, so we should add support for that.

Run benchmarks replacing Vec by the one in the smallvec crate, and see if it's worth it to add a dependency.

This function would receive an expression and return a boolean indicating whether the expression is valid.

The use case for this is that it should be significantly faster than eval since we don't have to evaluate anything. In particular, we wouldn't need to call parse which is the slowest part of eval.

We can try to use something like the Mode pattern described here to avoid code duplication between eval and check.

Check if it's possible/easy to make the crate work in no-std environments.

This function does not contribute much to the library, the only justification for its existence is performance, but we should first make some benchmarks on it (vs eval). If the difference is not big enough to justify complicating the API, we should deprecate it.

Crate evalexpr is also an arithmetic evaluator, we should compare our results with it.

Using the glc crate we can generate random expressions based on a context-free grammar. With this we are able to randomly and programatically generate the arithmetic expressions that are accepted by mexe in bulk for more comprehensive testing. Can help with issue #4.

We are just testing a few examples so far, with unit tests. This approach is not enough to guarantee that eval is 99.99% bug-free. Use something more thorough like quickcheck for that. If necessary, we can check the results of eval against other libraries such as meval.

The parse of "1)" should fail with an Err but it is returning Ok(1).

It might be worth trying to parallelize the parsing of numbers (str::parse). Whenever we find a number token, we can call a thread to do the str::parse.

Before implementing this, write a proof of concept to check if it's worth the benefit.

This would be under a feature, since it would probably require some dependency (tokio, rayon,...?).