I disagree a little with what @hdima said. The goal of this exercise is to practise pattern matching and not use any operators. The best way with pattern matching is to write down every case. So for b_or what are the different possible cases for the arguments? There are 4: true , true ; true , false ; false , true ; and false , false . So just write down each case as a separate clause returning the correct value:

b_or(true, true) -> true;
b_or(true, false) -> true;
b_or(false, true) -> true;
b_or(false, false) -> false.

So looking at this answer you could be thinking well as many cases are the same why not optimise this to:

b_or(false, false) -> false;
b_or(_, _) -> true.

_ is the don't care variable which matches anything and never gets bound. Well, both version behave the same if called with boolean values BUT they behave differently if called with non-boolean values. In this case the second returns true while the first one generates an exception. Usually it is better to generate an exception on bad input rather than let it pass and return a misleading answer, so the first alternative is a better solution.
Writing b_and (and b_xor ) is left to you.
Sorry if this was a bit long but pattern matching can take some getting used to. The concept of writing down what you expect and not how to test for it is different from what is common in OO and imperative languages. (I give courses and this is a common hurdle)

If you limited only to pattern matching b_not/1 should looks like this:

b_not(false) -> true;
b_not(true) -> false.

Try to use this idea for the other functions.

• Hint: for the other functions you don't need to write clauses for every possible case.*