Luke Boswell (Oct 24 2022 at 06:04): Luke Boswell (Oct 24 2022 at 06:04):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.
Brian Carroll (Oct 24 2022 at 07:17):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
Brian Carroll (Oct 24 2022 at 07:19):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.
Luke Boswell (Oct 24 2022 at 08:59):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...
Folkert de Vries (Oct 24 2022 at 09:07):hmm, this would mean that either option is confusing
Folkert de Vries (Oct 24 2022 at 09:07):maybe we should have the formatter insert parens here?
Folkert de Vries (Oct 24 2022 at 09:08):rust will ask you to insert parens in certain cases to clarify the order (even when rust technically knows the order, I think)
Richard Feldman (Oct 24 2022 at 14:51):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
Richard Feldman (Oct 24 2022 at 14:52):in fact this is the first time in my career I've seen it come up :big_smile:
Last updated: Jul 26 2025 at 12:14 UTC