feelin
feelin copied to clipboard
nikku
Failed to match boolean value
Maybe I misunderstood something, but the two behaviors (trivial Boolean logic) below are weird?
- https://nikku.github.io/feel-playground/?e=true&c=%7B%0A++%22%3F%22+%3A+false%0A%7D%0A&t=unaryTests&st=true
- https://nikku.github.io/feel-playground/?e=false&c=%7B%0A++%22%3F%22+%3A+false%0A%7D%0A&t=unaryTests&st=true
Just so that I understand the issue properly.
What about this scenario, what should the unary test return?
https://nikku.github.io/feel-playground/?e=3+%3C+1&c=%7B%0A++%22%3F%22+%3A+false%0A%7D%0A&t=unaryTests&st=true
Do we ONLY match by value in the very specific case where both the value and test are a simple boolean?
@nikku
I believe it's already fixed up by nikku? The initial problem was comparisons with zero (not the case here). Again, fixed, I guess.
I believe it's already fixed up by nikku? The initial problem was comparisons with zero (not the case here). Again, fixed, I guess.
No, this is not fixed (yet). ? denotes the current value, it is matched against a unary test.
If we enter a test that is always truthy 3 > 1 = true then we match whatever ? is against the result of that test, i.e. true if ? = true, else false.
Looking into our own documentation:
A unary-tests expression returns true if one of the following conditions is fulfilled:
- !! The expression evaluates to true when the input value is applied to it.
- The expression evaluates to a list, and the input value is equal to at least one of the values in that list.
- !! The expression evaluates to a value, and the input value is equal to that value.
- The expression is equal to - (a dash).
The issue here is that for booleans, the two scenarios highlighted via !! are ambiguous. A small improvement would be to always compare boolean values to their test by value, but then it leads to other errors:
?: true*, test: < 5
true < 5 becomes 1 < 5 becomes true**
true* === true** becomes true ✔️
?: false*, test: < 5
false < 5 becomes 0 < 5 becomes true**
false* === true** becomes false ❌
So I guess the "bug" that exists within the codebase is that we do not discriminate between when the expression itself is driven by the test value vs when it isn't.
An example, if I understand it correctly, is that we expect false, 0 > 1 => true but false, ? > 1 => false. But the current way we do things is that we first compute the expression part, and then compare it to the test value, so we have no way to differentiate these two scenarios.
@nikku
@Skaiir I'm not sure I fully understand what you mean. What would help is if you'd file a PR that contributes test cases to show which cases currently conflict.
If we find an actual conflict we could raise this with the DMN TCK to get clarity across all implementors.
On a related note, please do not trust documentation, but the standard.
Related discussion in feel-scala: https://github.com/camunda/feel-scala/issues/864#issuecomment-2188837091.
TLDR: We want to assess our current handling of such cases.