CaseOfCase UPLC transformation tests.

[Unisay]

• Chores: extract caseOfCase tests from Simplifier module into a dedicated test module.
• Chores: a bit of re-formatting (1st commit)
• A test case that demonstrates how CaseOfCase UPLC transformation changes program evaluation result in a presence of Error. (2nd commit)

Untyped Plutus Core
  CaseOfCase
    CaseOfCase/1:                                  OK
    CaseOfCase/2:                                  OK
    CaseOfCase/3:                                  OK
    Transformation doesn't evaluate error eagerly: FAIL
      untyped-plutus-core/test/Transform/CaseOfCase/Test.hs:92:
      expected: EvaluationSuccess (Constant () (Some (ValueOf DefaultUniUnit ())))
       but got: EvaluationFailure
      Use -p '/CaseOfCase/&&/Transformation doesn'\''t evaluate error eagerly/' to rerun this test only.

• Fix for the CaseOfCase UPLC transformation to make the test above pass.

Closes #5958

[effectfully]

Lots of nitpicking, sorry.

Thank you for confirming that there's a bug in case-of-case indeed.

I'm not convinced by the solution, because case-of-case is supposed to be an optimization and if we're adding force-delay that aren't required in many cases, then are we even making things better?

I'm OK with merging the PR though, a not-too-optimizing optimization is certainly better than a broken one. We can always think of a better solution later.

[effectfully]

BTW, if anybody is confused why we even bother optimizing ifThenElse b (constr <...>) (constr <...>), then here's where we produce such expressions:

[Unisay]

• Rebased on master.
• Addressed review comments.
• Isolated caseOfCase transformation in tests.

[ana-pantilie]

BTW, if anybody is confused why we even bother optimizing ifThenElse b (constr <...>) (constr <...>), then here's where we produce such expressions:

@effectfully why are those functions defined the way they are? Nvm, I see it's because you need to convert from bools to builtin bools. This builtin machinery is so awkward in so many places...

[effectfully]

One budget golden file change? When there were like 20 in the original PR? I don't get it, gonna take a look.

[effectfully]

@Unisay or feel free to take a look yourself why we're not seeing more changes here.

[effectfully]

Don't use /, use </> or joinPath. Those handle weird corner cases correctly and are cross-platform. Also we have the TestNested machinery for doing these things, but I see that it wasn't in these tests originally.

[effectfully]

@ana-pantilie

Nvm, I see it's because you need to convert from bools to builtin bools. This builtin machinery is so awkward in so many places...

This is very much by design, originally the builtins machinery would return a regular Plutus bool (Scott-encoded back then), but folks wanted me to remove that feature and return built-in bools instead, so I did that in like 2019.

Although now that you mention it, we'll hopefully soon be able to return SOPs from builtins, sounds like we need to come full circle and add builtins returning SOP bools directly.

In any case, for you it's obvious that we should return SOPs and not doing so seems awkward. But for, say, Aiken people it's obvious that we should return constants instead, because they prefer to pretend that SOPs don't exist. It's all subjective.

[effectfully]

I've reviewed this once again, I don't think any of my comments are blockers, so let's merge it and do follow-ups:

1. why did only one budget test changed? That's quite weird
2. should we avoid generating force-delay when branches are pure?

@zliu41 please still review this PR.

[effectfully]

Oh, and great work, thank you @Unisay!

[effectfully]

@Unisay just made an issue for you, not urgent. I decided not to dive into it for now, so hopefully you could.