Recognize if-like Tree.MultiSegmentApp as IfThenElse IR

[JaroslavTulach]

Pull Request Description

Fixes #9165 by recognizing if/then/else in a special way. Introduces new IfThenElse IR element to represent both if_then_else as well as if_then cases. Such element needs to be recognized by various IR processing passes and at the end converted into executable IfThenElseNode in IrToTruffle.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.
  • Discontinuing to support if_then_else methods?
• Are engine benchmarks OK? Still OK?

[JaroslavTulach]

To keep compatibility with original if_then_else and if_then method invocations, following code:

from Standard.Base import all

type X
    Ok
    Bad

    if_then_else self ~t ~f = case self of
        X.Ok -> t
        X.Bad -> f

    if_then self ~t = case self of
        X.Ok -> t
        X.Bad -> Nothing

main =
    a = X.Ok.if_then_else "true" "false"
    b = X.Bad.if_then_else "true" "false"
    c = if X.Ok then "true" else "false"
    d = if X.Bad then "true" else "false"

    x = X.Ok.if_then "true"
    y = X.Bad.if_then "true"
    z = if X.Ok then "true"
    w = if X.Bad then "true"


    [a, b, c, d, x, y, z, w]

should print ['true', 'false', 'true', 'false', 'true', Nothing, 'true', Nothing]. As of fba42c5 it doesn't do that. E.g. compatibility is broken.

It has to be Boolean!

Decision: The condition of if then else controlflow construct has to yield a Boolean-like value. No dispatch to if_then_else method will happen. Use v.if_then_else (trueAction) (falseAction) if you insist on the method dispatch semantics.

[JaroslavTulach]

Instrumenter_Spec tests are failing probably because we don't support instrumentation inside of case of statements!? fyi @4e6.

[JaroslavTulach]

While working on this PR I realized that we represent every case_of branch as a separate function. Can we speed something up by delaying the IR processing when we need such a closure?

Creating wip/jtulach/LazyIfCaseOfBranches9165 branch and measuring startup again and engine. Let's see the result!

[JaroslavTulach]

After running engine benchmarks it looks like just converting IfThenElse to Case.Expr isn't really speeding up anything.

Quite contrary. The most essential benchmark is slowing down. I guess direct conversion of IfThenElse to a Truffle node is needed.

This state of work is now preserved as ConvertingIfThenElseToCaseExpr and this PR will try to go different direction.

[JaroslavTulach]

Standard library tests are green: https://github.com/enso-org/enso/actions/runs/11582091869/job/32244310882?pr=11365

Next: Fix error reporting - e.g. unit tests

[Akirathan]

The overall direction seems good. What are your intentions regarding scoping rules of the if-then-else branches?

[Akirathan]

nit: You don't have to specify the name "profile" here. It is OK to just specify @Shared. As long as the parameter name is the same as in the other specialization, the shared annotation will work as expected.

[Akirathan]

nit: val modifier is redundant for parameter of case class primary constructor

[Akirathan]

Testing scopes of if then else is a good idea. I would like to see more expanded tests. Something like:

x = True
if x then
  y = True
  if x then if y then "Foo"

and

x = False
cond = False
if cond then "cond" else
  y = False
  if x then "x" else
    if y then "y" else 42

that is, try to use bindings from various parent scopes in the condition, true branch and false branch.

These tests could be placed in Base_Tests as well I believe.

[Akirathan]

IfThenElse as a builtin IR is indeed better than representing it as Application.Prefix with 2 arguments

[Akirathan]

I don't understand the requirement that you cannot override a binding from parent scope in the branches. The true branch and else branch is nothing more than a block of expressions, right? The following code:

foo ~action =
    action

main =
    x = 42
    foo <|
        x = 23
        x

prints 23, so it let's me override the x from the parent scope as well.

Is this the desired state or is this still WIP?