4 ms·

I'm not expert in any of this stuff, but reading that slide, I was kind of getting the impression that existential types and higher-kinded types are being unifi

I'm not expert in any of this stuff, but reading that slide, I was kind of getting the impression that existential types and higher-kinded types are being unified, in the grand scheme of Dotty exploiting theoretical equivalences of previously separated concepts. Same with the type parameter/member thing. I think the idea is that syntax will support both options, as seen with the analogous introduction of the value parameter syntax for traits, but the underlying implementation will be abstract members. This seems like it will make writing type level code or interop code much simpler, because there's only one underlying implementation to worry about. But re-reading your comment, I think you agree with that benefit. Do you know why abstract members were chosen as the underlying implementation? Are they more general? I agree that native HList functionality within tuples and case classes would be really huge for practical programming. It's a huge pain to abstractly define transformations over families of classes. It's awesome that Shapeless works, but more native support within the language could maybe help remove some of the challenge of actually using Shapeless.

lmm 12y ago
> I think the idea is that syntax will support both options, as seen with the analogous introduction of the value parameter syntax for traits, but the underlying implementation will be abstract members. Right; my problem here is that type inference handles type parameters fine and often doesn't handle type members without an explicit type. If the implementation is always type members that means we're always in the unpleasant case. > Do you know why abstract members were chosen as the underlying implementation? Are they more general? Yeah they are - there are some things you can't express as type parameters that you can express as type members. But there's value in making the simple case simple.
- acjohnson55 12y ago
  Ah gotcha. Well, can't the type inference just work the same as it does now, if you happen to use type parameters? And possibly, couldn't type inference that works in these cases be extended to type members? I would hope that this would be a side benefit of pushing towards more formal and unified underpinnings of surface features.
  - lmm 12y ago
    > Well, can't the type inference just work the same as it does now, if you happen to use type parameters? I think it can only work with type parameters because they're constrained in what they can do. If type parameters compile down to type members, presumably there is no "marker" that says that that type member obeys those constraints - if there is then it wouldn't really be unification of type members and type parameters.

lmm 12y ago

> I think the idea is that syntax will support both options, as seen with the analogous introduction of the value parameter syntax for traits, but the underlying implementation will be abstract members. Right; my problem here is that type inference handles type parameters fine and often doesn't handle type members without an explicit type. If the implementation is always type members that means we're always in the unpleasant case. > Do you know why abstract members were chosen as the underlying implementation? Are they more general? Yeah they are - there are some things you can't express as type parameters that you can express as type members. But there's value in making the simple case simple.

acjohnson55 12y ago
Ah gotcha. Well, can't the type inference just work the same as it does now, if you happen to use type parameters? And possibly, couldn't type inference that works in these cases be extended to type members? I would hope that this would be a side benefit of pushing towards more formal and unified underpinnings of surface features.
- lmm 12y ago
  > Well, can't the type inference just work the same as it does now, if you happen to use type parameters? I think it can only work with type parameters because they're constrained in what they can do. If type parameters compile down to type members, presumably there is no "marker" that says that that type member obeys those constraints - if there is then it wouldn't really be unification of type members and type parameters.