Add quotes.Type.valueOfConstant

[nicolasstucki]

With quote pattern matching it is possible to match over the structure of a type, this add to possility to extract the values from constant types.

This is esential to provide handle Mirror.{MirroredLabel, MirroredElemLabels} witthout needing reflection.

[liufengyun]

This is essential to provide handle Mirror.{MirroredLabel, MirroredElemLabels} without needing reflection.

It seems to me using reflection in such cases agrees with the design philosophy of doing complex things in reflection. There are several concerns:

(1) adding ad-hoc methods is difficult to learn & remember.
(2) the approach does not scale, in contrast to the more principled approach based on reflection.
(3) it's not clear that Type.valueOfConstant is different from a utility reflection method in essence.

[nicolasstucki]

This is essential to provide handle Mirror.{MirroredLabel, MirroredElemLabels} without needing reflection.

It seems to me using reflection in such cases agrees with the design philosophy of doing complex things in reflection. There are several concerns:

The design philosophy is to make simple thing easy and safe and complex things possible. The following points go against it.
Mirror should be simple to handle.

(1) adding ad-hoc methods is difficult to learn & remember.

It is in the same place all other methods on type are located. It is also the simplest part of the whole matching on Mirrors logic, if a user knows how to match against a mirror this operation will be trivial.

(2) the approach does not scale, in contrast to the more principled approach based on reflection.

Scale how? This is the leaf of the operations that we need, scaling to complex types is already handled by pattern match. The point is to have a safe and simple API. Using reflection is not a principled way to do it unless you redefine this operation in each project that needs it (i.e. every project matching on mirrors).

(3) it's not clear that Type.valueOfConstant is different from a utility reflection method in essence.

It is type-safe.

[liufengyun]

Scale how?

It seems we are adding more methods that are based on reflection to achieve type-safety --- I'm wondering what is the criteria for doing/not-doing so. This is the concern about scalability in my mind.

This is the leaf of the operations that we need, scaling to complex types is already handled by pattern match.

Maybe valueOfConstant should be an extractor for literal types?

[nicolasstucki]

Scale how?

It seems we are adding more methods that are based on reflection to achieve type-safety --- I'm wondering what is the criteria for doing/not-doing so. This is the concern about scalability in my mind.

Not sure how this could scale. We will probably not be adding more singleton constant type to the language any time soon.

This is the leaf of the operations that we need, scaling to complex types is already handled by pattern match.

Maybe valueOfConstant should be an extractor for literal types?

That was a mistake we previously did with the extraction of values out of expression. It made it harder to use and in many cases ended up calling the same extractor several times. The solution was to add Expr.value which does the same as this method.

[liufengyun]

Scale how?

It seems we are adding more methods that are based on reflection to achieve type-safety --- I'm wondering what is the criteria for doing/not-doing so. This is the concern about scalability in my mind.

Not sure how this could scale. We will probably not be adding more singleton constant type to the language any time soon.

This is the leaf of the operations that we need, scaling to complex types is already handled by pattern match.

Maybe valueOfConstant should be an extractor for literal types?

That was a mistake we previously did with the extraction of values out of expression. It made it harder to use and in many cases ended up calling the same extractor several times. The solution was to add Expr.value which does the same as this method.

I think the context is different. For Expr.Value, it's a problem because there is the design choice whether we should introduce Const(x) or introduce a more general Unlift(v). There is no such concern here.

[nicolasstucki]

Still, we need this if we want people to write type class derivation using macros without them doing horrible workarounds.

Without this we would make the complex part simple and the trivial part hard. That isn't a good idea.

[liufengyun]

LGTM

I'll leave you to decide whether it's better to be an extractor or not.