I’m glad to see this is recognized.
My doubts about DH aren’t so much about the features itself or the implementation cost. They are rather practical: what will people do with it?
I’m a big fan of F*, which does have dependent types… but is also a rather specialized language for specific use cases. Additionally, it allows to extract F# code. For a language that has such a specific use case and transpiles to something else, there’s less caution to be had.
For Haskell, I’m specifically wondering about:
- if depedent types will eventually be used in
base, what effect will this have on newcomers? - will I be exposed to type-spaghetti in every second library? What will this do to APIs?
I think these questions are really hard to answer and I understand they are probably not much considered when designing DH, because it’s really difficult to say.
That said, I’m much more a fan of liquidhaskell or the idea to just write a superset language of Haskell that transpiles back to it. Those things are clean and totally opt-in. Once this lands in Haskell proper, it will no longer be opt-in, even if it’s behind a language pragma.
The challenge with sequential incremental steps is that it may never lead to a satisfying design as a whole.