Add support for custom IntType, FloatType

[jvliwanag]

Looking for support for custom IntType, FloatType within an evaluation. In particular, was hoping to us evalexpr with decimal.

It would be better to be able to provide these types as type parameters instead of having rust feature flags enforce the types at compile time. This way, one evaluation can use say, f64 float type, whereas another portion can use Decimal float type.

[ISibboI]

That is a good idea!

If we set the current types as default, it might even stay backwards compatible.

On Sat, 30 Jul 2022, 11.31 Jan Vincent Liwanag, @.***> wrote:

Looking for support for custom IntType, FloatType within an evaluation. In particular, was hoping to us evalexpr with decimal https://crates.io/crates/decimal.

It would be better to be able to provide these types as type parameters instead of having rust feature flags enforce the types at compile time. This way, one evaluation can use say, f64 float type, whereas another portion can use Decimal float type.

— Reply to this email directly, view it on GitHub https://github.com/ISibboI/evalexpr/issues/111, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASATXUMS3PGJUA6SUH5OPTVWTR67ANCNFSM55C3VDOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[NatanFreeman]

As discussed here default types for function traits are not yet possible. Unless there is another means of accomplishing this, adding traits to the existing eval functions would break compatibility. We would either have to create yet another class of eval functions that allow specifying types or just give up on backwards compatibility.

[ISibboI]

As described in https://github.com/ISibboI/evalexpr/issues/122#issuecomment-1565286387, a way to work around many issues with custom numeric types is to get rid of the current distinction between integers and floats. Instead, add just one generic number type, which can then distinguish between integers and floats internally.

The idea for implementation would roughly be:

• Replace Value::Int and Value::Float with Value::Number and make Value generic over the number type.
• Specify the number type via an associated type to the Context trait.
• Add a NumberType trait, maybe make it compatible with num-traits somehow.
  • NumberType should require the relevant std::ops.
  • NumberType is responsible for parsing itself from a string.
• Token would also be generic over the number type.

Open questions are:

• [ ] What happens to builtin functions? If they are specified by the NumberType trait, then adding new builtin functions would become a breaking change each time. Possibly it is best to move them into a BuiltinFunctionsContext and then add composable contexts (#81) for using builtin functions. Then the number type would only specify "basic" mathematical functions, and only if a new builtin function requires a not-yet-specified operation it would become a breaking change.
• [ ] HashMapContext has a Value in one of its fields. Can this be made generic via the implementation of Context without giving HashMapContext a type parameter? Would a type parameter here be bad?
• [ ] Making Value generic makes a lot of other types generic. Would it be better to instead have Value::Number contain a Box<dyn NumberType>?
• [x] Review existing code and see what else comes up.