Make type of type hole available in quoted patterns #10045

nicolasstucki · 2020-10-20T08:48:53Z

Current state

In general, instances of scala.quoted.Type are and should not be used explicitly in quotes.

+ def f[T](x: T)(using Type[T])(using QuoteContext) = 
+   '{ val y: T = $x; ... } // good code

- def f[T](x: T)(using t: Type[T])(using QuoteContext) = 
-   '{ val y: t.T = $x; ... } // bad code

- def f[T](x: T)(using t: Type[T])(using QuoteContext) = 
-   '{ val y: $t = $x; ... } // bad code (syntax will be removed)

The only exception is on types extracted using quoted patterns as these hide tier type inside an instance of Type[T] which must be accessed using it's path.

??? match 
  case '{ $x: $t } =>
-   '{ val y: t.T = $x; ... } // bad code
-   '{ val y: $t = $x; ... } // bad code (syntax will be removed)

Here t is provided as a given as if we refer to its type we must be able to summon it.

Changes

The change is to provide the name of the type that is extracted rather than the given Type[T].
Type[T] can be summoned were needed as in all other uses of abstract types in quotes.

??? match 
  case '{ $x: $T } =>
+   '{ val y: T = $x; ... } // good code
-   val t: Type[T] = summon[Type[T]]
-   '{ val y: t.T = $x; ... } // bad code
-   '{ val y: $t = $x; ... } // bad code (syntax will be removed)

The pattern will make T and a given Type[T] available on the right-hand side of the pattern.
The T can be used the same way it could be used in the implementation of a method with signature:

def f[T](x: T)(using Type[T])(using QuoteContext) = 
  '{ val y: T = $x; ... }

case '{ $x: $T } =>
  '{ val y: T = $x; ... }

It is also possible to use lower cases for the type splices case '{ $x: $t } => '{ val y: t = $x; ... }.
This is similar to the use of type variables in normal patterns case Some[t](x) =>.
It is preferable to use upper cases as it makes it clearer that this is a type and renders better on the uses in the right-hand side of the pattern.

nicolasstucki · 2020-10-20T09:16:49Z

Note that this was the original design but we went the other way due to technical challenges while typing the quoted patterns. Now I see that it was actually not that complicated to implement this, just had to use semantic names correctly.

nicolasstucki · 2020-10-20T13:34:22Z

The syntax discussion is out of the topic of this PR. We should have it on a proper issue. I will create one later.

nicolasstucki · 2020-10-20T14:21:02Z

I created #10050 to follow up the syntax discussions

liufengyun

Otherwise, LGTM

liufengyun · 2020-10-20T18:35:24Z

compiler/src/dotty/tools/dotc/core/NameOps.scala

+            && (n != true_)
+            && (n != null_))
+        }
+      } || name.is(PatMatQuoteTypeEv)


Why this change is needed? This kind of specialization is not scalable.

For a $T we need to create a name while typing for the given Type[T] that will be available if the pattern matched. We need to use a semantic name to make sure that this name does not leak into userspace. This change makes this particular kind of semantic name be a valid pattern var to make typer handle it as such.

I don't see any other case where we would use something like this and therefore I'm not sure we need it to scale. If we have another use-case in the future we can revise this and create a more general mechanism. We could achieve the same if we use an attachment on the Ident to mark such trees but this would come with some extra runtime overhead.

Looking at it, PatMatQuoteTypeEv is not needed for anything specific quote wise. I can rename to VarPattern or something like that.

Now it scales to any other synthetic var pattern.

liufengyun · 2020-10-20T18:54:43Z

tests/pos-macros/i6997c.scala

      '{
-        val tmp: $t = $x
+        val tmp: T = $x


This is not as symmetric as before. I think meta-programmers will be at a loss about whether to use $ or not before a type.

It is not symmetric because it is not intended to be as quoted types do not follow the same level symmetry that expression do. The syntax $ for types won't exist outside of patterns and hence they will have a single option and won't be able to get confused about this at the use site. The use of $ in the pattern is its own issue (see #10050) which we will address separately. Here we focus on the use sites and keep the changes to the patterns to a minimum.

In general, instances of `scala.quoted.Type` are and should not be used explicitly in quotes. ```diff + def f[T](x: T)(using Type[T])(using QuoteContext) = + '{ val y: T = $x; ... } // good code - def f[T](x: T)(using t: Type[T])(using QuoteContext) = - '{ val y: t.T = $x; ... } // bad code - def f[T](x: T)(using t: Type[T])(using QuoteContext) = - '{ val y: $t = $x; ... } // bad code (syntax will be removed) ``` The only exception is on types extracted using quoted patterns as these hide tier type inside an instance of `Type[T]` which must be accessed using it's path. ```diff ??? match case '{ $x: $t } => - '{ val y: t.T = $x; ... } // bad code - '{ val y: $t = $x; ... } // bad code (syntax will be removed) ``` Here `t` is provided as a `given` as if we refer to its type we must be able to summon it. The change is to provide the name of the type that is extracted rather than the `given Type[T]`. `Type[T]` can be summoned were needed as in all other uses of abstract types in quotes. ```diff ??? match case '{ $x: $T } => + '{ val y: T = $x; ... } // good code - val t: Type[T] = summon[Type[T]] - '{ val y: t.T = $x; ... } // bad code - '{ val y: $t = $x; ... } // bad code (syntax will be removed) ``` The pattern will make `T` and a `given Type[T]` available on the right-hand side of the pattern. The `T` can be used the same way it could be used in the implementation of a method with signature: ```scala def f[T](x: T)(using Type[T])(using QuoteContext) = '{ val y: T = $x; ... } ``` ```scala case '{ $x: $T } => '{ val y: T = $x; ... } ``` It is also possible to use lower cases for the type splices `case '{ $x: $t } => '{ val y: t = $x; ... }`. This is similar to the use of type variables in normal patterns `case Some[t](x) =>`. It is preferable to use upper cases as it makes it clearer that this is a type and renders better on the uses in the right-hand side of the pattern.

liufengyun

LGTM

liufengyun · 2020-10-21T15:04:30Z

compiler/src/dotty/tools/dotc/core/NameOps.scala

+            && (n != true_)
+            && (n != null_))
+        }
+      } || name.is(PatMatVarName)


The renaming makes everything much more clear 👍

Indeed. The scalability concern made me realize that it was just a misnomer.

After scala#10045 we do not have any cases where we need to use this type reference explicitly in the source code. We rename it to have a descriptive name to improve error messages and to push users to use the canonical representation of types and never use them explicilty.

nicolasstucki self-assigned this Oct 20, 2020

nicolasstucki force-pushed the quoted-type-pattern branch 2 times, most recently from 9748734 to 6d329ca Compare October 20, 2020 09:35

nicolasstucki changed the title ~~Make type of type hole available quoted patterns~~ Make type of type hole available in quoted patterns Oct 20, 2020

nicolasstucki force-pushed the quoted-type-pattern branch from 6d329ca to 3f038b4 Compare October 20, 2020 10:59

This comment has been minimized.

Sign in to view

nicolasstucki force-pushed the quoted-type-pattern branch from 3f038b4 to 1fd6034 Compare October 20, 2020 12:18

This comment has been minimized.

Sign in to view

nicolasstucki force-pushed the quoted-type-pattern branch from 1fd6034 to b3e09f9 Compare October 20, 2020 13:37

nicolasstucki mentioned this pull request Oct 20, 2020

Improve syntax of type holes in quoted patterns #10050

Closed

nicolasstucki mentioned this pull request Oct 20, 2020

Warn users on non canonical type references #9952

Merged

nicolasstucki marked this pull request as ready for review October 20, 2020 14:51

nicolasstucki requested a review from liufengyun October 20, 2020 14:59

nicolasstucki assigned liufengyun and unassigned nicolasstucki Oct 20, 2020

nicolasstucki force-pushed the quoted-type-pattern branch from b3e09f9 to 3cc348e Compare October 20, 2020 16:02

liufengyun approved these changes Oct 20, 2020

View reviewed changes

nicolasstucki force-pushed the quoted-type-pattern branch from 3cc348e to 12764e2 Compare October 21, 2020 12:20

nicolasstucki added 2 commits October 21, 2020 16:55

Homogenize pattern var method names

f700dda

Add synthetic pattern var names

7bc0173

nicolasstucki force-pushed the quoted-type-pattern branch from ee86bbc to 7bc0173 Compare October 21, 2020 14:59

liufengyun approved these changes Oct 21, 2020

View reviewed changes

nicolasstucki requested a review from liufengyun October 21, 2020 15:18

nicolasstucki merged commit a3c3396 into scala:master Oct 22, 2020

nicolasstucki deleted the quoted-type-pattern branch October 22, 2020 08:00

nicolasstucki mentioned this pull request Oct 27, 2020

Rename Type.T to Type.Underlying #10097

Merged

Kordyjan added this to the 3.0.0 milestone Aug 2, 2023

Make type of type hole available in quoted patterns #10045

Make type of type hole available in quoted patterns #10045

Uh oh!

Conversation

nicolasstucki commented Oct 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Current state

Changes

Uh oh!

nicolasstucki commented Oct 20, 2020

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nicolasstucki commented Oct 20, 2020

Uh oh!

nicolasstucki commented Oct 20, 2020

Uh oh!

liufengyun left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

liufengyun left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nicolasstucki commented Oct 20, 2020 •

edited

Loading