Is this a bug or am I missing something obvious? Seems to be working correctly in the REPL. Do roc repl
and roc test
use different compilers or something?
expect Bool.and Bool.true Bool.true == Bool.true
expect Bool.true && Bool.true == Bool.true
expect Bool.false && Bool.true == Bool.false
expect Bool.true && Bool.false == Bool.false
expect Bool.false && Bool.false == Bool.false
luke@192-168-1-108 roc-aoc-2021 % roc test ppppp.roc
── EXPECT FAILED ─────────────────────────────────────────────────── ppppp.roc ─
This expectation failed:
20│ expect Bool.false && Bool.true == Bool.false
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
── EXPECT FAILED ─────────────────────────────────────────────────── ppppp.roc ─
This expectation failed:
22│ expect Bool.false && Bool.false == Bool.false
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2 failed and 3 passed in 507 ms.
No, there is only one compiler!
Can you share exactly what did you put into the repl that worked? Did it include the expect keyword? One side of the = or both sides?
I suspect parentheses might fix it.
My guess would be that it's being parsed as
expect Bool.false && (Bool.false == Bool.false)
which would be false overall, thus "failing" the test
And I would further guess that you only put the left hand side of the ==
into the REPL? Because then this order of operations confusion wouldn't crop up.
Thank you. You are correct, it looks like the order of operations. Should it work that way? It doesn't seem right to me.
Referring to the Order of Operations Wiki referenced in the tutorial there seems to be different implementations in different languages. Does Roc intend to align with C
style languages? Either way I think we could update the tutorial for others to be more explicit.
Quote from the wiki
Dennis Ritchie, creator of the C language, has said of the precedence in C (shared by programming languages that borrow those rules from C, for example, C++, Perl and PHP) that it would have been preferable to move the bitwise operators above the comparison operators.[26] Many programmers have become accustomed to this order, but more recent popular languages like Python and Ruby do have this order inversed. The relative precedence levels of operators found in many C-style languages are as follows...
hmm, this would mean that either option is confusing
maybe we should have the formatter insert parens here?
rust will ask you to insert parens in certain cases to clarify the order (even when rust technically knows the order, I think)
I think the current behavior is preferable because the only situation where it's confusing is when you do == Bool.true
or == Bool.false
which can always be rewritten as something more concicse, so this comes up super rarely in practice
in fact this is the first time in my career I've seen it come up :big_smile:
Last updated: Jul 06 2025 at 12:14 UTC