Skip to content
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

toExprOfTuple method with precise types #7047

Merged
merged 3 commits into from
Aug 30, 2019

Conversation

anatoliykmetyuk
Copy link
Contributor

Blocked by #7046.

@anatoliykmetyuk anatoliykmetyuk force-pushed the liftable-derivation branch 3 times, most recently from c462bc7 to 6bc5952 Compare August 15, 2019 13:53
@anatoliykmetyuk anatoliykmetyuk self-assigned this Aug 16, 2019
@anatoliykmetyuk anatoliykmetyuk force-pushed the liftable-derivation branch 2 times, most recently from eb4b8be to de89441 Compare August 22, 2019 15:22
@anatoliykmetyuk
Copy link
Contributor Author

Rebased on master

@anatoliykmetyuk
Copy link
Contributor Author

@nicolasstucki I have implemented some extra safety for this one.

  val tpl2: (Expr[1], 2, Expr[3]) = ('{1}, 2, '{3})
  '{val res = ${tpl2.toExprOfTuple}; res}  // error

In the previous implementation, this would have resulted in a class cast exception when doing asInstanceOf[Seq[Expr[_]] on the sequence representation of the tuple. In this implementation, we use an implicit predicate to verify that the tuple's type is correct. Furthermore, the implicit predicate also verifies the correctness of the match type InverseMap: the predicate assembles the result type in a logic programming style and then requires it to be equal to InverseMap which is visible to the end-user.

Hence, here we achieve safety without corrupting the end user's API. I believe this is a better way to go than having an Error["message"] type which forces the compiler to have an error: the input type, not the result type, is the one to be constrained.

I believe this pattern of having a companion predicate for match types can be a good safeguard when the match type is meant to be a partial type lambda, not a total one, and we need to verify the input type.

This still feels rather cumbersome though... Maybe we can find something more idiomatic.

Thanks @OlivierBlanvillain for helping with the solution.

@anatoliykmetyuk anatoliykmetyuk force-pushed the liftable-derivation branch 3 times, most recently from 4fa3275 to e7bc58c Compare August 27, 2019 14:07
@anatoliykmetyuk
Copy link
Contributor Author

Rebased

@nicolasstucki
Copy link
Contributor

The CI did not run for some reason

@anatoliykmetyuk anatoliykmetyuk merged commit ac7a2b0 into scala:master Aug 30, 2019
@anatoliykmetyuk anatoliykmetyuk deleted the liftable-derivation branch August 30, 2019 09:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants