Tests to Explore Typeclass Derivation #5497
Conversation
They are redundant, and can cause a cyclic reference when trying to evaluate a lazy body annotation. We did filter them before, but not everywhere.
- package case bindings with reduced expression - don't map wildcards to TypeTrees
This one resembles Magnolia, in that it uses some degree of reflection
... and some polishings
We could not reduce a pattern with wildcard type arguments because these were not treated as GADT bound variables but as abstract types.
|
@milessabin: https://github.com/dotty-staging/dotty/tree/inline-for-derive/tests/run/typeclass-derivation2.scala is a test case for first stab at typeclass derivation. It would be good to have your feedback on this. |
It can happen that what is really a constant type is still in the form of an unreduced MatchType. We need to normalize the type to reveal the constant. The new version typeclass-derivation2.scala test needs this fix to compile without errors.
and some related renamings
|
@nicolasstucki The PR contains some smallish fixes to the inliner that makes the tests compile correctly. Can you do a quick review of these? |
|
The changes in the |
There was a problem hiding this comment.
The changes in the compiler look good. I'll le @milessabin give feedback on the derivation test cases/example.
|
@odersky I think this looks good as a proof of concept ... and it satisfies me that inline/match gives us a good set of primitives to work with. I have some issues with the encodings you've used (both forms), but I think, as you say, it's a good starting point. I'm going to take a stab at eliminating (or at least reducing the number of) handwritten folds, seeing if we can make (as much as possible of) the intermediate representation erasable, and generalizing to type classes indexed by higher kinded types (eg. |
|
@odersky I'm happy for this to be merged as-is, given that it contains needed fixes. |
|
Ahh ... I'm the one assigned ... I'll merge :-) |
Two different typeclass derivation schemes in typeclass-derivation{1,2}.scala. The second scheme is preferable: it generates more efficient code and needs fewer (generated or hand-written) instance definitions.
This is a first stab at the problem; there are lots of opportunities for optimizations.