I like this work, but I’m not a fan of the new forall a -> syntax, which I worry is too easily confused with the existing forall a. syntax.
Haskell already has too much syntax, and too much of it is subtle (“why can’t I pattern match on type names?”), surprising (“wait, this ~> syntax is a user-defined operator?”) or undiscoverable (“wait, @ means something special when this language extension is enabled?”). As someone who is fluent, I appreciate the brevity, but I think it adds a lot of unnecessary difficulty to the learning curve.
Very pleased to see the ExplicitNamespaces extension as opposed to the proposal to merge the type and value namespaces. At the Haskell Symposium last year, I was among the only voices advocating against creating affordances for merging the namespaces.
I love the idea of dependent types in a language as useful as Haskell. But so so so much more, I’d love to see developers of this calibre working purely (lulz) on improving Haskell compile times and similar earthly concerns.
This is cool, although I share the distaste for that forall a syntax. It seems like this work is focused on enabling references to types in the term-level language. Not knowing much about the implementation of dependent types in general or in GHC specifically, I’m curious if that’s because enabling terms in types is significantly more challenging.
I like this work, but I’m not a fan of the new
forall a ->syntax, which I worry is too easily confused with the existingforall a.syntax.Haskell already has too much syntax, and too much of it is subtle (“why can’t I pattern match on type names?”), surprising (“wait, this
~>syntax is a user-defined operator?”) or undiscoverable (“wait,@means something special when this language extension is enabled?”). As someone who is fluent, I appreciate the brevity, but I think it adds a lot of unnecessary difficulty to the learning curve.Very pleased to see the ExplicitNamespaces extension as opposed to the proposal to merge the type and value namespaces. At the Haskell Symposium last year, I was among the only voices advocating against creating affordances for merging the namespaces.
I love the idea of dependent types in a language as useful as Haskell. But so so so much more, I’d love to see developers of this calibre working purely (lulz) on improving Haskell compile times and similar earthly concerns.
This is cool, although I share the distaste for that
forall asyntax. It seems like this work is focused on enabling references to types in the term-level language. Not knowing much about the implementation of dependent types in general or in GHC specifically, I’m curious if that’s because enabling terms in types is significantly more challenging.