Use Values to create and match value Exprs

[nicolasstucki]

Currently Expr(x) is used to create code that will produce a copy of the value. In extractors, it will take the code that creates a copy of the value and will create a copy of the value and return it. So far it was not always clear to everyone what is the difference between Expr(...) and '{...}. Using Value and constructor/extractor the intention of the code clearer.

• Replace Expr.apply with Value.apply
• Replace Expr.unapply with Value.unapply
• Replace Exprs.unapply with Values.unapply
• Aligns with expr.value and expr.valueOrError
• Deprecate old definitions in 3.0.0-M3 and remove them in 3.0.0-RC1 for simpler migration
• Add back deprecated Unlifted, unlift and unliftOrError to help migration from 3.0.0-M2 to 3.0.0-M3

Migration from 3.0.0.M2

// Create an expression that will create a copy of the value
- val expr = Expr(x)
+ val expr = Value(x)

// Create an `Option` of a copy of the value in the expression
- expr.unlift
+ expr.value

// Create a copy of the value in the expression or report an error
- expr.unliftedOrError
+ expr.valueOrError

// Match a value in an expression and recreate an expression that will create the same value
- expr match
-   case Unlifted(x) => Expr(x)
+ expr match
+   case Value(x) => Value(x)

// Matching nesteed values
- expr match
-   case '{ pow(${Unlifted(x)}, ${Unlifted(n)} } => Expr(pow(x, n)) 
+ expr match
+   case '{ pow(${Value(x)}, ${Value(n)} } => Value(pow(x, n)) 

// Extract varargs and get the value of each argument
- case '{ StringContext(${Varargs(partsExprs @ Unlifed(parts))}: _*) } =>
+ case '{ StringContext(${Varargs(partsExprs @ Values(parts))}: _*) } =>

[liufengyun]

• Replace Expr.apply with Value.apply

I find it counter-intuitive with respect to Scala convention. In Scala, when we call C.apply, we construct a value of the type C.

[nicolasstucki]

We do the same to create an Option[Int] using Some(3).

To be complete we could add type Value[+T] <: Expr[T]. This would imply that we could do something like

expr match
  case expr: Value[T] => expr.get
  case _ =>

But those operations would be more expensive at runtime than the current ones.

[deusaquilus]

So now instead of:

def intValue: Expr[Int] = Expr(something)

It will be?

def intValue: Expr[Int] = Value(something)

This seems unnecessarily confusing. What is the motivation?

It seems this is one of those things that completely makes sense from the internals knowing the internals of the Tasty-Reflect API but it utterly confusing for a new user who might want to learn tasty macros.

[nicolasstucki]

The motivation is that @liufengyun preferred Value instead of Expr to match on expressions containing values

expr match
  case '{ foo(${Value(x)})} => x

And we need to keep them in sync to avoid further confusion. I did not mind Expr.

[deusaquilus]

Why can't you do something like Expr.Value for that? It seems like a special case for which it should not be necessary to change the entire API.

[nicolasstucki]

It would be a bit too long for an operation that we use all the time.

[deusaquilus]

Is there anything else you can do other then rename the Expr constructor? Any other thing you could possibly change the value-match API to? Knowing that 'Value' needs to be used to construct 'Expr' is really, really confusing to a new user that does not know Tasty-Reflect internals. I really want many people to be able to this API easily.

Right now it's just me annoying you about this stuff but in half a year when more people start using this API they'll start yelling about these things that will look like inconsistencies to them.

Literally, any solution for this is better other renaming the entire Expr-constructor API.

[nicolasstucki]

I was not convinced by this change from the start. I promised I would try it out to find out if it was a good idea. It clearly has more drawbacks than what I originally anticipated. Thank you for all the feedback.