More reliable short-cicruiting behavior for || and && operators.

[Unisay]

Before the fix:

  ShortCircuiting operators
    (&&) short-circuits with GHC optimisations:    OK
    (||) short-circuits with GHC optimisations:    OK
    (&&) short-circuits without GHC optimisations: FAIL
      test/ShortCircuit/Spec.hs:50:
      An error has occurred:  User error:
      The machine terminated because of an error, either from a built-in function or from an explicit use of 'error'.
      Use -p '/ShortCircuiting/&&/(&&) short-circuits without GHC optimisations/' to rerun this test only.
    (||) short-circuits without GHC optimisations: FAIL
      test/ShortCircuit/Spec.hs:50:
      An error has occurred:  User error:
      The machine terminated because of an error, either from a built-in function or from an explicit use of 'error'.
      Use -p '/ShortCircuiting/&&/(||) short-circuits without GHC optimisations/' to rerun this test only.

2 out of 4 tests failed (0.01s)

After the fix:

  ShortCircuiting operators
    (&&) short-circuits with GHC optimisations:    OK
    (||) short-circuits with GHC optimisations:    OK
    (&&) short-circuits without GHC optimisations: OK
    (||) short-circuits without GHC optimisations: OK

All 4 tests passed (0.01s)

The fix is implemented as a code rewrite when compiling an expression:
a && b is rewritten as if a then b else False
a || b is rewritten as if a then True else b

Based on this un-merged PR.

Closes #4114

[michaelpj]

I don't really like special-casing certain functions in the compiler. But I think I am outvoted on this 🤷

[zliu41]

@Unisay A few more comments.

PlutusTx.Bool.&& and || should now be marked NOINLINE, since we don't need their unfoldings.

I don't really like special-casing certain functions in the compiler.

@michaelpj Yeah but if anything should be special-cased, it's && and ||, since they are special in almost all other strict languages.

[zliu41]

There's a Note [Short-circuit evaluation for && and ||] which is now out of date.

The Note should be rewritten to explain that saturated applications of && and || always short-circuit, but unsaturated applications won't.

[zliu41]

I wonder if we should raise an error if || and && is used unsaturated. Or at least a warning, but I don't know that the Plutus Tx compiler has the ability to emit warnings.