Losing HKT would be a shame, but that's a trade-off I would be willing to make.
The issue you're looking for (since an ask for HKTs typically means that Typeclasses are the ideal feature) is here: https://github.com/fsharp/fslang-suggestions/issues/243
Please leave opinions, commentary, and vote if this is something you want! F# language design is done completely in the open, including motivation for features. Thanks!
They're really good at saying "No" to things that offer at best incremental improvements at the cost of significant complexity.
"Profunctor Optics" is a great example. Cool paper, but no thanks.
Do you have examples of why it would add significant complexity? I use them constantly and it really simplifies my code a lot!
Also, I don't believe 'profunctor optics' is a paper, I think it's just one (interesting) implementation of optics, which are useful in any language that encourages immutability.
"Cool paper but no thanks" is a saying for when people come to you with an extremely new technique and want you to incorporate it at the language level with very little proofing in the field.
"Profunctor optics" is the a description of how profunctors encode lenses and similar structures. I am aware. I also think that technique can cook in Haskell land for a few more years before non-research projects should uptake it.
As for the 'cool paper' comment, I wasn't aware of this new jargon, thanks for informing heh. I'm not sure how well it will play outside of haskell, I've done a Scala encoding of them and it's a bit more awkward than other representations.
But it's also worth noting that this is not a rejection of the entire concept of lenses, just that right now Haskell's implementations leave a lot to be desired (e.g., abandon all error sanity, ye who enter here).
Haskell is as much a research platform as a programming language, and as such it has the leisure to experiment this way. Everyone else will wait awhile for things to bake. Look what happened when Haskell built its entire stdlib on monad transformers and then we all realized they're awful compared to the alternatives.
This is why I love working on an open project like F#. We get to disagree in public! I would actually like Typeclasses, though I have serious reservations in terms of not breaking back compatibility. I'm certainly not about to get on a table and rant about how "it was truly the lack of better ad-hoc polymorphism via higher-kinded types that kept me from writing good software in F#!", and I see a danger in bifurcating the language .... but I like Typeclasses and think they do solve some more nuanced issues out there.
I should probably be putting my opinions on the Typeclasses thread...
"With higher-kinded types [...] type operators can be parameterized by other type operators. Java doesn’t support higher-kinded types, but, if it did, you would be able to write something like this:"
class GraphSearch<T> {
T<Node> frontier;
}