9 ms·

Most of the comments so far are negative, so I'll add something positive. One thing I love about the Haskell community is how they are always questioning their

Most of the comments so far are negative, so I'll add something positive. One thing I love about the Haskell community is how they are always questioning their assumptions and genuinely seeking the best way to do things (often drawing upon or contributing to computer science research). The core concepts behind Haskell are clean and simple (essentially something between System F and System Fω), but there's a lot of baggage on the surface that obscures that underlying elegance. We should encourage people taking an introspective look into their tools and asking how they can be better, even if certain proposals are unrealistic or controversial. I think the author is just writing down their opinions (which are worth discussing!) and not seriously trying to start a new GHC frontend. Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types (which are actually simpler than where Haskell has been heading) rather than building increasingly complex approximations of them. Once you try a dependently typed language like Agda, Lean, Coq, or Idris, it's hard to go back to the complexity of having two (or more!) separate languages for types and programs. Regarding the proposals in the article, the most interesting to me is (2), although I'm not sure about some of the specifics. In general, I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It's harder to talk about Haskell when everyone is using a different flavor of it.

codeflo 3y ago
> Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types To give a counter point, there seem to be lots of small wins that aren't taken, possibly in part because people seem to wait for the big ideas. Take partial functions like head: You can do what Haskell and Java do and throw an exception. Or you can have dependent types and statically prevent the function from being applied to an empty list. But the obvious and easy solution in the current language would be to return Maybe, which isn't done because there's a feeling that it's not a big enough step to be worth the effort, and dependent types will eventually solve this anyway.
- Quekid5 3y ago
  That's an interesting counterpoint, but I think it's a bit of a different tradeoff. Adding, say, dependent types, can be done as a gradual process with opt-in (via language extensions) and "only" requires heroic effort on the part of the compiler writers... whereas changing 'head' requires 10000i Hackage packages to update their code. This is all tied into how inflexible the base/Prelude story is currently, etc. If the Prelude were a fully independent library where you could just depend on any old version you like, then there'd be no problem changing the signature. (Other than the usual diamond dependency problems). Of course you can choose NoPrelude and go from there, but then you're already in a place where changing 'head' doesn't matter to you, only the maintainer of your alternative Prelude. People are working on both of these aspects, and that's got me really excited about where Haskell is going these days! (I've always loved Haskell as a language, but there have been undeniable ecosystem issues.)
- yakubin 3y ago
  In cases when head is used though, you clearly just want to unpack the first element of a list. So if you replace head with a function that returns a Maybe, all you’re going to do is pattern match on its result to check if it’s a Just. So I don’t see a benefit over matching x::_ against the list straight away. (I do see how a function like that is useful, but I don’t think it’s a good replacement for head.)
  - nyssos 3y ago
    > all you’re going to do is pattern match on its result to check if it’s a Just Something is eventually going to pattern match on it. But it might well be some handler way way up at the top of my program, and all I want to do right now is `map` and `bind` as normal.
    - yakubin 3y ago
      Then you're clearly not using head. For this you can use listToMaybe. Don't change the meaning of an identifier to something meant for a completely different use. The alternative change involving dependent types or liquid types doesn't break existing code. Changing head so that it returns a Maybe breaks code, because its use case is different.
mhitza 3y ago
> I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It's harder to talk about Haskell when everyone is using a different flavor of it. That is what the standardization process is for. I don't think that the parties that could write a new Haskell standard have the time, resources, or bandwidth to work on one. That's why for now we're stuck with 98, 2010 and a bunch of extensions.
tome 3y ago
> I think Haskell needs a way to graduate (or retire) language extensions That sounds like the Extension lifecycle framework proposal https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/ghc-proposals/ghc-proposals/pull/601
LeanderK 3y ago
> embracing dependent types (which are actually simpler than where Haskell has been heading) rather than building increasingly complex approximations of them very much second that! haskell has band-aid type-level programming that is so awful, but sometimes so useful, that it's really hurting a lot. I would just really like to deprecate type-families and would like to see as a the first step some non-dependently typed type-promoted functions. There's a great, pragmatic, proposal I would really like to see implemented. I, personally, don't need dependent types thaaaaaat much but type families are so unergonomic and really a dead-end I think. It's just stupid. it's sad to see that the dependent haskell progress is losing steam and, as it is my impression, getting maybe a bit lost in the weeds?
- whateveracct 3y ago
  DTs aren't losing steam at all. There are people chugging along implementing them.
benreesman 3y ago
I really like the Haskell that goes easy on the dependent-type sort of stuff: and I say that as someone who has been on-call for Sigma (which is like, top 3 industrial use cases). It’s just really, really expressive without trying to solve the halting problem via some unification failure mode. Type classes and GADTs already give you 10x the canvas you can get without trouble anywhere else, and if you keep it tight, you have the tooling to really tune it up. Idris is awesome, do that if you’re doing that. Haskell is changing all the time: it became a serious production tool: I’d really like for it to stay one.
- nyssos 3y ago
  Haskell's current dependent typing is expressive, but also painful to use and almost impossible to debug. The main thing I want out of dependent Haskell isn't more power (though I wouldn't turn it down), it's the ability to write type-level Haskell like Haskell instead of some early Prolog prototype.

codeflo 3y ago

> Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types To give a counter point, there seem to be lots of small wins that aren't taken, possibly in part because people seem to wait for the big ideas. Take partial functions like head: You can do what Haskell and Java do and throw an exception. Or you can have dependent types and statically prevent the function from being applied to an empty list. But the obvious and easy solution in the current language would be to return Maybe, which isn't done because there's a feeling that it's not a big enough step to be worth the effort, and dependent types will eventually solve this anyway.

Quekid5 3y ago
That's an interesting counterpoint, but I think it's a bit of a different tradeoff. Adding, say, dependent types, can be done as a gradual process with opt-in (via language extensions) and "only" requires heroic effort on the part of the compiler writers... whereas changing 'head' requires 10000i Hackage packages to update their code. This is all tied into how inflexible the base/Prelude story is currently, etc. If the Prelude were a fully independent library where you could just depend on any old version you like, then there'd be no problem changing the signature. (Other than the usual diamond dependency problems). Of course you can choose NoPrelude and go from there, but then you're already in a place where changing 'head' doesn't matter to you, only the maintainer of your alternative Prelude. People are working on both of these aspects, and that's got me really excited about where Haskell is going these days! (I've always loved Haskell as a language, but there have been undeniable ecosystem issues.)
yakubin 3y ago
In cases when head is used though, you clearly just want to unpack the first element of a list. So if you replace head with a function that returns a Maybe, all you’re going to do is pattern match on its result to check if it’s a Just. So I don’t see a benefit over matching x::_ against the list straight away. (I do see how a function like that is useful, but I don’t think it’s a good replacement for head.)
- nyssos 3y ago
  > all you’re going to do is pattern match on its result to check if it’s a Just Something is eventually going to pattern match on it. But it might well be some handler way way up at the top of my program, and all I want to do right now is `map` and `bind` as normal.
  - yakubin 3y ago
    Then you're clearly not using head. For this you can use listToMaybe. Don't change the meaning of an identifier to something meant for a completely different use. The alternative change involving dependent types or liquid types doesn't break existing code. Changing head so that it returns a Maybe breaks code, because its use case is different.

mhitza 3y ago

> I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It's harder to talk about Haskell when everyone is using a different flavor of it. That is what the standardization process is for. I don't think that the parties that could write a new Haskell standard have the time, resources, or bandwidth to work on one. That's why for now we're stuck with 98, 2010 and a bunch of extensions.

tome 3y ago

> I think Haskell needs a way to graduate (or retire) language extensions That sounds like the Extension lifecycle framework proposal https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/ghc-proposals/ghc-proposals/pull/601

LeanderK 3y ago

> embracing dependent types (which are actually simpler than where Haskell has been heading) rather than building increasingly complex approximations of them very much second that! haskell has band-aid type-level programming that is so awful, but sometimes so useful, that it's really hurting a lot. I would just really like to deprecate type-families and would like to see as a the first step some non-dependently typed type-promoted functions. There's a great, pragmatic, proposal I would really like to see implemented. I, personally, don't need dependent types thaaaaaat much but type families are so unergonomic and really a dead-end I think. It's just stupid. it's sad to see that the dependent haskell progress is losing steam and, as it is my impression, getting maybe a bit lost in the weeds?

whateveracct 3y ago
DTs aren't losing steam at all. There are people chugging along implementing them.

benreesman 3y ago

I really like the Haskell that goes easy on the dependent-type sort of stuff: and I say that as someone who has been on-call for Sigma (which is like, top 3 industrial use cases). It’s just really, really expressive without trying to solve the halting problem via some unification failure mode. Type classes and GADTs already give you 10x the canvas you can get without trouble anywhere else, and if you keep it tight, you have the tooling to really tune it up. Idris is awesome, do that if you’re doing that. Haskell is changing all the time: it became a serious production tool: I’d really like for it to stay one.

nyssos 3y ago
Haskell's current dependent typing is expressive, but also painful to use and almost impossible to debug. The main thing I want out of dependent Haskell isn't more power (though I wouldn't turn it down), it's the ability to write type-level Haskell like Haskell instead of some early Prolog prototype.