docu updates

Readme.md

@@ -62,12 +62,11 @@ assert_eq!(result, u32::MAX - 1);
 
 ## Benchmarks
 
-Exmex was created with flexibility (e.g., arbitrary names of binary and unary operators and a custom regex 
-for number literals), ergonomics (e.g., just finds variables), and evaluation speed in mind. On the other
+Exmex was created with flexibility (e.g., use your own operators, literals, and types), ergonomics (e.g., just finds variables), and evaluation speed in mind. On the other
 hand, Exmex is slower than the other crates during parsing. 
 However, evaluation might be more performance critical depending on the application. 
 
-The expressions used for benchmarking are:
+The expressions used to compare Exmex with other creates are:
 ```
 sin:     "sin(x)+sin(y)+sin(z)",
 power:   "x^2+y*y+z^z",
@@ -100,7 +99,7 @@ Note that we also tried the optimization flag `--emit=asm` which did not change
 
 Exmex parsing can be made faster by only passing the relevant operators. 
 
-The crate [Evalexpr](https://docs.rs/evalexpr/6.3.0/evalexpr/) has been removed from the benchmarking since it could not evaluate the case `nested` correctly and it was rather slow anyway. The crates [Mexprp](https://docs.rs/mexprp/0.3.0/mexprp/) and [Asciimath](https://docs.rs/asciimath/0.8.8/asciimath/) did not run without errors on Win10. More details about the benchmarking can be found in the [source file](https://github.com/bertiqwerty/exmex/blob/main/benches/benchmark.rs). 
+The crate [Evalexpr](https://docs.rs/evalexpr/6.3.0/evalexpr/) has been removed from the benchmarking since it could not evaluate the `nested` case correctly and it was rather slow anyway. The crates [Mexprp](https://docs.rs/mexprp/0.3.0/mexprp/) and [Asciimath](https://docs.rs/asciimath/0.8.8/asciimath/) did not run without errors on Win10. More details about the benchmarking can be found in the [source file](https://github.com/bertiqwerty/exmex/blob/main/benches/benchmark.rs). 
 
 Note the unfortunate fact that Criterion does neither provide the option to simply report the minimum runtime nor to remove outliers before reporting a mean runtime as mentioned in the following [quote](https://bheisler.github.io/criterion.rs/book/analysis.html).
 > Note, however, that outlier samples are not dropped from the data, and are used in the following analysis steps along with all other samples.

src/lib.rs

@@ -1,5 +1,5 @@
 #![doc(html_root_url = "https://docs.rs/exmex/0.8.0")]
-//! Exmex is a fast **ex**tendable **m**athematical **ex**pression evaluator.  
+//! Exmex is a fast, simple, and **ex**tendable **m**athematical **ex**pression evaluator.  
 //! ```rust
 //! # use std::error::Error;
 //! # fn main() -> Result<(), Box<dyn Error>> {
@@ -17,7 +17,8 @@
 //! ## Variables
 //! For variables we can use strings that are not in the list of operators as shown in the following expression.
 //! Additionally, variables should consist only of letters, numbers, and underscores. More precisely, they need to fit the
-//! regular expression `r"^[a-zA-Z_]+[a-zA-Z_0-9]*"`.
+//! regular expression 
+//! ```r"^[a-zA-Z_]+[a-zA-Z_0-9]*"```.
 //! Variables' values are passed as slices to [`eval`](FlatEx::eval).
 //! ```rust
 //! # use std::error::Error;
@@ -34,23 +35,23 @@
 //! The `n`-th number in the slice corresponds to the `n`-th variable. Thereby only the
 //! first occurence of the variables is relevant. In this example, we have `z=2.5` and `y=3.7`.
 //! If variables are between curly brackets, they can have arbitrary names, e.g.,
-//! `{456/549*(}`, `{x}`, and `{x+y}`  are valid variable names as shown in the following.
+//! `{456/549*(}`, `{x}`, and confusingly even `{x+y}` are valid variable names as shown in the following.
 //! ```rust
 //! # use std::error::Error;
 //! # fn main() -> Result<(), Box<dyn Error>> {
 //! #
 //! use exmex::{make_default_operators, parse};
 //! let x = 2.1f64;
 //! let y = 0.1f64;
-//! let to_be_parsed = "log({x+y})";  // {x+y} is the name of one(!) variable, not the sum of two 😕.
+//! let to_be_parsed = "log({x+y})";  // {x+y} is the name of one(!) variable 😕.
 //! let expr = parse::<f64>(to_be_parsed, &make_default_operators::<f64>())?;
 //! assert!((expr.eval(&[x+y])? - 2.2f64.ln()).abs() < 1e-12);
 //! #
 //! #     Ok(())
 //! # }
 //! ```
 //! ## Extendability
-//! Library users can also define a different set of operators as shown in the following.
+//! Library users can define their own set of operators as shown in the following.
 //! ```rust
 //! # use std::error::Error;
 //! # fn main() -> Result<(), Box<dyn Error>> {
@@ -84,9 +85,9 @@
 //! type [`Option<BinOp<T>>`](Operator::bin_op) and
 //! [`Option<fn(T) -> T>`](Operator::unary_op), respectively, as
 //! members. [`BinOp`](BinOp)
-//! contains in addition to the operator [`op`](BinOp::op) of type `fn(T, T) -> T` an
+//! contains in addition to the function pointer [`apply`](BinOp::apply) of type `fn(T, T) -> T` an
 //! integer [`prio`](BinOp::prio). Operators
-//! can be both, binary and unary such as `-` as defined in the list of default
+//! can be both, binary and unary. See, e.g.,  `-` defined in the list of default
 //! operators. Note that we expect a unary operator to be always on the left of a
 //! number.
 //!