New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Short circuit ops for booleans (over QQ) #4191
Conversation
I think I'd rather have the simpler typed-TH version, no need for quasiquotation parser failure or anything like that.
Location looks fine. Would be nice to have a test witnessing the lazy behaviour. |
@michaelpj Ok, I've added tests, for simple cases and to prove the lazy evaluation. |
There is a bit of problem with multiline versions.
It will report line of the error as beginning of the and_if. |
@michaelpj can we simply define (&&) :: Bool -> Bool -> Bool
(&&) = \x y -> if x then y else False
{-# INLINE (&&) #-} This is pretty much guaranteed to get inlined and we'll get the right short-circuiting semantics as long as GHC doesn't attempt to optimize the resulting Although maybe (&&) :: Bool -> Bool -> Bool
x && y = if x then y else False
{-# INLINE (&&) #-} would be a bit more reliable? |
We could do that. My main concern was that then we have surprising behaviour in a different way: we have a function call where the arguments are not evaluated strictly! That's also surprising. But maybe it's less surprising, I don't really know. (Both your variant should be the same in PIR) |
That sounds kind of bad, like following a lesser of two evils approach |
Fixes #4114
The problem is that plutus booleans don't use short circuit on evaluation.
There is ugly fix to rewrite all expressions with
if-then-else
.But code becomes rather clumsy. We can fix that with meta TH.
Proposed fix defines two qq-functions
and_if
andor_if
:[and_if| expr1, expr2, expr3]
for arbitrary number of arguments is expanded to
and
[or_if| expr1, expr2, expr3]
is expanded to