On that area, I kind of remember there are fslang-suggestions entries discussing options for numeric literals to remain generic, and I think it is not the area (considering the client API side, not the implementation details of some of the internal numeric code) that would yield the most benefits for the end users (given current state of F# language wrt numeric literals and generic numeric code).
I'm saying this because IIRC, I brought the idea that in the new "model" we are sketching for 3.0 API in some of the discussions, DecisionName could well be a domain / client code type, rather than an arbitrary string wrapper that Flips enforces on consumers.
I think if this would be a valid design, and the library could still retain a default same feeling as 2.0 API, it would increase the client domain signal ratio in the formulation and reporting/result extraction code, to a similar extent that units of measure are already enabling.
So this issue is to discuss this space of the design, how we can explore it, and come to a consensus on what can be achieved.
This is to discuss issues related to elements of the model that have potential of being lifted as a generic type parameter of some of the types.
In issue https://github.com/fslaborg/flips/issues/141#issuecomment-752205563 @TysonMN brought the topic of the numeric type used (
float) and discussed possibility to adjust the types.On that area, I kind of remember there are fslang-suggestions entries discussing options for numeric literals to remain generic, and I think it is not the area (considering the client API side, not the implementation details of some of the internal numeric code) that would yield the most benefits for the end users (given current state of F# language wrt numeric literals and generic numeric code).
I'm saying this because IIRC, I brought the idea that in the new "model" we are sketching for 3.0 API in some of the discussions, DecisionName could well be a domain / client code type, rather than an arbitrary string wrapper that Flips enforces on consumers.
I think if this would be a valid design, and the library could still retain a default same feeling as 2.0 API, it would increase the client domain signal ratio in the formulation and reporting/result extraction code, to a similar extent that units of measure are already enabling.
So this issue is to discuss this space of the design, how we can explore it, and come to a consensus on what can be achieved.