Add support for custom IntType, FloatType
Opened this issue · 4 comments
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.
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.
As described in #122 (comment), 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
andValue::Float
withValue::Number
and makeValue
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 withnum-traits
somehow.NumberType
should require the relevantstd::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 aBuiltinFunctionsContext
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 aValue
in one of its fields. Can this be made generic via the implementation ofContext
without givingHashMapContext
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 haveValue::Number
contain aBox<dyn NumberType>
? - Review existing code and see what else comes up.
Not sure this is a proper proposal here to the problem but one way we could be "faster" to implement things here is to use some "syntax" to differentiate between types. One example of such a way is to use sigils. For example, in Elixir we can write something like: ~D[2024-01-01]
and this is a proper Date
struct.
The syntax is simply:
- starts with
~
- uses a discriminator (which can be a single letter or a stream of letters)
- uses some separator which can be any of
[]
,//
, etc... - has the value between the separators
- can have modifiers after the end of the separator (can be flags for the parser)
We could make this small syntax uplift and it would be easy to have both 0.1
as a float and something like ~f/0.2/
be a Decimal. We could then extend to ~$/R$ 4,32/
be a money amount and so on.
Would this be welcome as a contribution?