Some useful tree constructors

[liufengyun]

In implementing ScalaTest macros, I find two tree constructors are useful:

def selectApply(receiver: Term, name: Name, args: List[Term]): Term
def let(expr: Term)(body: Ident => Term): Term

The constructor selectApply should do overloading resolution internally, but no other adapation (like inserting apply nor implicits). The constructor let allows creating bindings friendly.

The current implementation of assert is as follows:

      case Term.Apply(Term.Select(lhs, op), rhs :: Nil) =>
        op match {
          case "==" =>
            val left = lhs.seal[Any]
            val right = rhs.seal[Any]
            '{
              val _left   = ~left
              val _right  = ~right
              val _result = _left == _right
              val _bool = Bool.binaryMacroBool(_left, ~op.toExpr, _right, _result, ~prettifier)
              Assertions.assertionsHelper.macroAssert(_bool, ~clue, ~pos)
            }
          case ">" =>
            // blocked by tasty constructors
            // https://github.com/lampepfl/dotty/pull/5438
            val left = lhs.seal[Int]
            val right = rhs.seal[Int]
            '{
              val _left   = ~left
              val _right  = ~right
              val _result = _left > _right
              val _bool = Bool.binaryMacroBool(_left, ~op.toExpr, _right, _result, ~prettifier)
              Assertions.assertionsHelper.macroAssert(_bool, ~clue, ~pos)
            }

With the two constructors, the implementation can be made more generic & simpler:

case Term.Apply(Term.Select(lhs, op), rhs :: Nil) =>
  val res =
  let(lhs) { left =>
    let(rhs) { right =>
      let(selectApply(left, op, right)) { result =>
         val l = left.seal[Any]
         val r = right.seal[Any]
         val b = result.seal[Boolean]
        '{
            val _bool = Bool.binaryMacroBool(~l, ~op.toExpr, ~r, ~b, ~prettifier)
            Assertions.assertionsHelper.macroAssert(_bool, ~clue, ~pos)      
         }
    }
  }
  res.seal[Assertion]

[nicolasstucki]

Those should not be implemented in the core. They should be implemented in some library. The let abstraction is already in https://github.com/nicolasstucki/quoted-util

[smarter]

Those should not be implemented in the core. They should be implemented in some library.

Why ?

[liufengyun]

@nicolasstucki Just checked https://github.com/nicolasstucki/quoted-util, it seems they are not tasty reflect util, but quote util. I assume implementing overloading resolution will be a challenge in library?

[nicolasstucki]

Oh, yes. Those are not on trees. Though they are safer.

[nicolasstucki]

Here is the precise link https://github.com/nicolasstucki/quoted-util/blob/master/src/main/scala/quoted/util/Let.scala#L22-L25

[liufengyun]

The provided constructors are not enough:

• We lack API to create let-bindings (val-bindings) dynamically
• The way to support dynamic select on a term based on copy is awkward
• The semantics of Select.copy is unspecified in the case of overloading

We cannot use quote to introduce the binding, because we do not know the type of lhs and rhs statically.

        case Term.Apply(sel @ Term.Select(lhs, op), rhs :: Nil) =>
          case ">" =>
            val Term.IsSelect(select) = sel
            def app(l: Expr[Any], r: Expr[Any]): Expr[Boolean] =
              Term.Apply(Term.Select.copy(select)(l.unseal, ">"), r.unseal :: Nil).seal[Boolean]

            val left = lhs.seal[???]
            val right = rhs.seal[???]
            '{
              val _left   = ~left
              val _right  = ~right
              val _result = ~app('_left, '_right)
              Bool.binaryMacroBool(_left, ~op.toExpr, _right, _result, ~prettifier)
            }

It will be really nice to have something like let and selectApply or equivalent as proposed in the issue.

[nicolasstucki]

#5651 shows how to implement def let(expr: Term)(body: Ident => Term): Term in library code.

[liufengyun]

Those should not be implemented in the core. They should be implemented in some library.

I think core and non-core are just a problem of separation, there are multiple ways to achieve the separation, e.g. different packages, not neccesarily in different libraries.