-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Introduce Unliftable for Quasiquotes (take #3) #3255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously it also matched other nodes but returned Nil as value of xs. This behavior was added for sake of consistentcy with q”f[..$ts]”. On the other hand q”f[..$Nil]” == q”f” but q”f(..$Nil)” == q”f()” not q”f”. Due to this deconstruction/construction symmetry was broken. On the other hand applications also have q"f(...$xss)" option which is infact similar to q"f[..$ts]". Splicing Nil into it also results in q"f".
Contributor
|
I still don't think that names like |
Contributor
|
Speaking of things of questionable benefit, I'm also not convinced that we need to have a bunch of internally used names added to StandardNames. |
Previously trees that represent parameters, case clauses and type variables had strictly defined ValDef, TypeDef and CaseDef types which caused problems in compositionality. Now this checks are moved to runtime so it's possible to pass a tree that is CaseDef but has Tree type.
Previously we believed that having Liftable outside of the Universe will bring some advantages but it turned out this wasn’t worth it. Due to infectious nature of path dependent types inside of the universe one had to cast a lot. A nice example of what I’m talking about is a change in trait ArbitraryTreesAndNames. Additionally a number of standard Liftables is added for types that are available through Predef and/or default scala._ import: Array, Vector, List, Map, Set, Option, Either, TupleN.
This commit introduces internal attachment that allows unapply macros to be aware of their sub patterns and tweak their expansion depending on that info. At the moment this is not possible due to the way pattern macros are expanded: case MacroPat(inner1, inner2) => ... During type checking this will expand as MacroPat.unapply(<unapply-dummy>) Meaning that macro can’t see inner1 and inner2 in it’s macroApplication. To circumvent this we attach that info as an attachment to the dummy.
This commit performs a number of preliminary refactoring needed to implement unliftable: 1. Replace previous inheritance-heavy implementation of Holes with similar but much simpler one. Holes are now split into two different categories: ApplyHole and UnapplyHole which correspondingly represent information about holes in construction and deconstruction quasiquotes. 2. Make Placeholders extract holes rather than their field values. This is required to be able to get additional mode-specific information from holes (e.g. only ApplyHoles have types). 3. Bring ApplyReifier & UnapplyReifier even closer to the future where there is just a single base Reifier with mode parameter. Along the way a few bugs were fixed: 1. SI-7980 SI-7996 fail with nice error on bottom types splices 2. Use asSeenFrom instead of typeArguments in parseCardinality. This fixes a crash if T <:< Iterable[Tree] but does not itself have any type arguments. 3. Fix spurious error message on splicing of Lists through Liftable[List[T]]
Unliftable is a type class similar to existing Liftable that lets
users to extract custom data types out of trees with the help of
straightforward type ascription syntax:
val q“foo.bar(${baz: Baz})” = ...
This will use Unliftable[Baz] to extract custom data type Baz out of
a tree nested inside of the another tree. A simpler example would be
extracting of constant values:
val q”${x: Int} + ${y: Int}” = q”1 + 2”
1. Use (x1, x2): (T1, T2) instead of (x1: T1, x2: T2) 2. More detailed error message for improper function argument 3. Fix typo 4. Completely remove LiftableClass symbol from definitions
Member
|
LGTM, time to merge! |
retronym
added a commit
that referenced
this pull request
Dec 12, 2013
Introduce Unliftable for Quasiquotes (take #3)
This was referenced Apr 7, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rebase of #3211
review @retronym