10 ms·

I'm enjoying the read. Having written a fair deal of Haskell, I'm really grateful for what leaning Haskell told me about programming at large. Snoyman has writt

by cies 6y ago

I'm enjoying the read. Having written a fair deal of Haskell, I'm really grateful for what leaning Haskell told me about programming at large. Snoyman has written amazing libs and acute articles, and I appreciate this series a lot. My interest though are: what's next? Can Haskell evolve? Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. So what can be done? Could we come up with a new Haskell-spec version that fixes some of these, flips some pragmas to be on-by-default? I can imagine that laziness is not going out, it too much at the heart of the language: or am I just assuming that? But besides laziness there is a lot to fix by just setting a new standard. It will help newcomers, an eventually even old codebases may make the jump. Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? 1: https://stackoverflow.com/questions/42151927/what-is-haskell-missing-for-totality-checking https://stackoverflow.com/questions/42151927/what-is-haskell...

ivanbakel 6y ago
>Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? You don't need an advanced checker for partial functions - the link you use is discussing proving termination, but total vs partial functions just requires checking whether the function is defined for all arguments, which is easy and something that GHC can already do. And to be honest, I'm not sure we can do without. Partial functions and `error` (or `undefined`) are necessary escape hatches for the programmer who knows something the compiler doesn't. Partial functions should probably not end up in any APIs (and definitely not in the Prelude), but they are still an important part of the language. Only the introduction of dependent typing has the possibility of really eliminating partial functions for good.
- Ericson2314 6y ago
  The issue is not "undefined" and "error" but accidental partiality. `head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! The fact that https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop returns Option<T> really says it all. We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I wrote https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 to address just these sorts of issues, and not the harder ones people confuse them with.
  - ivanbakel 6y ago
    > The issue is not "undefined" and "error" but accidental partiality. I don't understand what you mean by this. >`head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! But the user can use `head` when they know that the list they are handling is non-empty (but then they can also opt for `Data.List.NonEmpty`). I never said the partial function itself carried any knowledge - only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. >We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I'm not opposed to that - and I don't see why you would think that I am. I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. That doesn't mean I believe they belong everywhere, and certainly not in most APIs.
    - cies 6y ago
      > I don't understand what you mean by this. I think that GP tries to say the escape hatches are not the problem. "error" and "undefined" are fine (we can check for undefined not being in production code, and errors, well, could be implemented as a "die" or "halt"). But head though... It should return a Maybe wrapped value! And as you say the other option is nonempty lists a.k.a. "(a, [a])". > only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. Well the docs do not present head as an escape hatch out of Haskell iron type system! It's documented rather innocently [1] (search for head). Unlike unsafePerformIO[2] and the likes, which have whole epistols detailing their danger. > I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. Please consider escape hatches differently from basic stuff like head and you see we argue for the same end result. Head is plain bad, should be removed or annotated as the smelly thing it is. maybeHead and non-empty-collections are the way fwd there, would you agree? 1: http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude.html http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude... 2: https://hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Syste...
gizmo686 6y ago
GHC already supports strict-by-default https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/stri... Obviously making it the default would be backwards incompatible. But, as long as lazyness remains supported and simple to use on a per-case basis, it doesn't actually seem like that big of a change to me. Also, the fact that GHC supports so many extensions actually gives a good path to updating the language. Since extension are enabled on a per-file basis, in most cases old libraries would just work with new-Haskell as long as the build system knows to build them in old-Haskell mode.
- nightski 6y ago
  I worked with Haskell for a few years and have a book on immutable data structures (Okasaki) in my book shelf here. From what I remember, with immutable data structures strict by default is actually a pretty bad default (please correct me if I remember wrong). I can only imagine this is one of the reasons Haskell is lazy by default (seriously, it's more than just that they wanted to try this crazy thing). Just enabling strictness everywhere in Haskell isn't just inherently better. Laziness is actually quite good (and the OP even says this to an extent). It's more nuanced than it seems.
  - gizmo686 6y ago
    For small amounts of data, strictness is better then laziness. There is a simmilar lesson even in non-pure languages: copying small amounts of data is almost always faster than fancy scheme you want to do to avoid copying. For large amounts of data in an immutable structure, laziness is pretty much essential. The theory behind strict-by-default is that most of the time, you are not dealing with large amounts of data; even if you have pointers to large data, or pointers to pointers of large data. Even though laziness is vital to a pure language, you only need to use it in a relatively small number of places.
    - dwohnitmok 6y ago
      Wait why is laziness vital to large data structures? Even with strict functions on strict, but persistent functions, you almost never copy the entire data structure. For example a strict function on a strict persistent list that swaps the head of the list doesn't have to copy the entire tail of the list. The thing that laziness enables is short-circuiting, so e.g. a fold over the list can bail out early if necessary. But this is actually a minority of use cases for large data, since we often bound the size of data structures with something like a `take n` function for some integer n, which only processes n elements in a strict language.
massysett 6y ago
Laziness - or more precisely, non-strictness - is the essence of Haskell. Haskell was created because there were a bunch of non-strict languages out there, and folks saw a need for one non-strict language to rule them all. Often a defining feature of Haskell is thought to be its purity. Purity arose from non-strictness. Monadic IO arose from non-strictness (other solutions to IO were also tried.) This is best discussed in a paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I guess you could make Haskell strict by default...but why? It wouldn't be Haskell anymore. Non-strictness is the defining element of the language. In my view a strict-by-default Haskell is...something else. Maybe it's better for certain things. Maybe it takes things to the next level. But it isn't Haskell. Don't call it that.
- rtpg 6y ago
  I think what’s being proposed around “strict data fields by default” (or, an alternative or “some new concept that evokes strictness where it makes sense”) could let us continue to use Haskell and its laziness. This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.
- mst 6y ago
  "strict-by-default" isn't really the proposal here. Only "some things' laziness is more a footgun than a feature, maybe we should consider fixing those". The foldl/sum/product example in part one is maybe clearer about that.
- cies 6y ago
  I understand the historic context of laziness, and what it "brought" or "taught" us. But is it really that important now, or moving forward? I side with Snoyman in the "strict by default would probably be better". Sure it's no longer Haskell then. But could there not be a language like Haskell leveraging strict by default? Possibly even on the GHC?
  - cycloptic 6y ago
    Isn't that basically every other ML variant?
3np 6y ago
Do you think there's any hope of Haskell community moving to Idris? It's years since I did either but I think Idris is just a Better Haskell without several of the issues brought up.
- lupire 6y ago
  For small programs, but not in general. Haskell has too many more language features and libraries.
mumblemumble 6y ago
> Can Haskell evolve? Should it? Haskell has already shown an impressive ability to evolve. Evolution is how it got where it is today. Language design analogues of the blood vessels being on the wrong side of the retina and all. If the goal remains to have an effective research language with a more-or-less unsurpassed capacity for evolution and pushing the state of the art in interesting directions, I'd say Haskell is still great just as it is. If, on the other hand, the goal is to have a productive industrial programming language that encompasses all of Haskell's great ideas, but without quite so many troublesome language warts, evolutionary vestiges, or {-# LANGUAGE EverythingInterestingThatsHappenedOverThePastThirtyYears #-}, it might be better to make a clean break.
- agentultra 6y ago
  GHC is a production-ready compiler (for Haskell) suited for industry use. I work on a growing, healthy team and we ship an application written in Haskell several times a day. It has decent tooling, which is improving, and the language itself is what makes it possible to tolerate the pace of those developments. Haskell isn't a pure "research-only" language. I realize people like to point out that it's original goal was research... however the nature of that research has changed over time. Take Galois' Crucible project where they used advanced dependent-types in order to write their security analysis tool [0]. They could have used research-grade dependently-typed languages that are much more expressive and easier to use... but they chose Haskell because they needed an industrial-grade compiler capable of producing fast code to run in a production setting. The kind of research being done in GHC and Haskell these days is bringing innovation and advancement in functional programming into industrial applications. Every compiler is going to have warts. Especially with people using it and depending on it for industrial use. That's a good thing. You could be like Lean 4 which will make no promises of backwards compatibility or consideration for industrial users in the name of staying purely for research. Although I agree that Haskell is impressive in its ability to evolve and grow! Linear types just landed in GHC 9.0.1 and many fine folks are improving the compiler to make way for dependent types. It's good stuff! And to see languages like Java, C#, C++, and others pick up on the low-hanging fruit of FP languages is a sign that the paradigm is gaining popularity and adoption: ADTs, lamdbas, type inference, pattern matching... Maybe in 20-30 years will see these languages adopting higher-kinded types, rank-n types, GADTs, and more? [0] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...
willtim 6y ago
IMHO Haskell is missing three features that would really improve programming in the large: 1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better. 2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules. 3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version. Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.
- Ericson2314 6y ago
  You realize 3 would make 1 and 2 harder or less valuable? And 3 would have also prevented a gazillion 1s and 2s from being still with us? I think breaking changes are highly underratted and people only shy away from them because the tooling expectations in all languages are so rock bottom.
  - willtim 6y ago
    > You realize 3 would make 1 and 2 harder or less valuable? Yes that is why I think (1) and (2) need a new language. > And 3 would have also prevented a gazillion 1s and 2s from being still with us? I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.
    - IngoBlechschmid 6y ago
      Isn't constructing a new language the ultimate breaking change :-)
SkyMarshal 6y ago
Keep Haskell as a research language imho, but perhaps create an industrial-oriented subset of the language, similar to Ada’s SPARK [1]. Make it strict if necessary, flip whatever pragmas support an industrial use case, etc., and create a separate brand but which still references Haskell. [1]:https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language)
js8 6y ago
> Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. He mentioned https://github.com/commercialhaskell/rio https://github.com/commercialhaskell/rio in the 1st article, it's interesting, I wasn't aware of it. (I am using classy-prelude but I might try it out.)
jrochkind1 6y ago
The OP addresses your question, saying he is not advocating for removing laziness, but does have some specific suggestions. > I'm not advocating for removing laziness in Haskell. In fact I'm not really advocating for much of anything in this series. I'm just complaining, because I like complaining. > But if I was to advocate some changes: * Deprecate partial functions * Introduce a naming scheme for partial functions to be more obvious * Introduce a compiler warning to note partial function use (with a pragma to turn off specific usages) * Warn by default on partial pattern matches * Advocate strict data fields by default
- colonwqbang 6y ago
  Change all partial functions from returning a to returning Maybe a. Then we rename the fromJust function into the $%&!# operator (name intended to suggest the exclamation made by the programmer when function fails).
- _ezkx 6y ago
  If StrictData were simply made the new default (with exceptions for lists and some other things in the standard lib), I bet very little code would break. It certainly wouldn't change the flavor of the language. I think it's a good idea.
tikhonj 6y ago
Haskell needs its own Elixir: a language different enough to fix fundamental problems but similar enough to inhabit the same world. I'm imagining a language with its own frontend and some of its own features that could still reuse GHC (maybe from Core down) and share libraries freely in both directions, while also able to address some fundamental issues without being constrained by backwards compatibility. I personally love Haskell: I think it's in a great place as a language (even if it isn't wildly popular) and on a positive trajectory. But I definitely feel the same pain points Snoyman brings up, and maybe some others. (Template Haskell >.<) I don't see any way of fixing many of the biggest issues if we care about backwards-compatibility at all, and a language with 30 years of existing code can never get away from that. I also don't think te community could weather a Python 2 → 3 transformation (much less Perl 5 → 6). So the only path I see towards simultaneously keeping what's great about Haskell and improving all that isn't would be another language that can coexist simultaneously, just like Elixir and Erlang.
- Kototama 6y ago
  PureScript would almost fit :-). It would just need a modern Haskell backend but having a strict language built on a lazy-one is probably not the best idea :-).
  - YawningAngel 6y ago
    You can avoid lazy behaviour entirely in Haskell if you want to, so your purescript to haskell compiler can just only generate contrived haskell code that doesn't exhibit laziness
  - cies 6y ago
    Idris maybe? If Idris has easy interop with the Rust ecosystem, we'd have a great backend (and with wasmer possibly also fontend) option.
    - Kototama 6y ago
      I was also thinking as Rust as a backend for a FP language in the last day. I found some Ocaml binding for Rust. It would be interesting to see how it fits.
cptwunderlich 6y ago
FYI there was a proposal for a "Haskell 2021 Language" Extensions (similar to Haskell 98 and 2010), which was approved. This enables a bunch of extensions (and I guess will become default): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p... That being said, while there are alternative preludes, I'm not sure how or when (or ever) the current prelude will be changed or replaced. In terms of language evolution, the community seems to focus on further extensions of the Type System (linear types, quicklook impredicativity, dependent types), where I think there is a bigger need in better tooling. Of course, there too, lots of things are happening, like haskell-language-server, ghc-debug etc. etc. But still lots of work to do. Would be great if more people worked on modern tooling and improving GHC. And even better if more companies would fund that =)

by cies 6y ago

ivanbakel 6y ago

>Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? You don't need an advanced checker for partial functions - the link you use is discussing proving termination, but total vs partial functions just requires checking whether the function is defined for all arguments, which is easy and something that GHC can already do. And to be honest, I'm not sure we can do without. Partial functions and `error` (or `undefined`) are necessary escape hatches for the programmer who knows something the compiler doesn't. Partial functions should probably not end up in any APIs (and definitely not in the Prelude), but they are still an important part of the language. Only the introduction of dependent typing has the possibility of really eliminating partial functions for good.

Ericson2314 6y ago
The issue is not "undefined" and "error" but accidental partiality. `head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! The fact that https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop returns Option<T> really says it all. We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I wrote https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 to address just these sorts of issues, and not the harder ones people confuse them with.
- ivanbakel 6y ago
  > The issue is not "undefined" and "error" but accidental partiality. I don't understand what you mean by this. >`head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! But the user can use `head` when they know that the list they are handling is non-empty (but then they can also opt for `Data.List.NonEmpty`). I never said the partial function itself carried any knowledge - only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. >We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I'm not opposed to that - and I don't see why you would think that I am. I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. That doesn't mean I believe they belong everywhere, and certainly not in most APIs.
  - cies 6y ago
    > I don't understand what you mean by this. I think that GP tries to say the escape hatches are not the problem. "error" and "undefined" are fine (we can check for undefined not being in production code, and errors, well, could be implemented as a "die" or "halt"). But head though... It should return a Maybe wrapped value! And as you say the other option is nonempty lists a.k.a. "(a, [a])". > only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. Well the docs do not present head as an escape hatch out of Haskell iron type system! It's documented rather innocently [1] (search for head). Unlike unsafePerformIO[2] and the likes, which have whole epistols detailing their danger. > I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. Please consider escape hatches differently from basic stuff like head and you see we argue for the same end result. Head is plain bad, should be removed or annotated as the smelly thing it is. maybeHead and non-empty-collections are the way fwd there, would you agree? 1: http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude.html http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude... 2: https://hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Syste...

gizmo686 6y ago

GHC already supports strict-by-default https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/stri... Obviously making it the default would be backwards incompatible. But, as long as lazyness remains supported and simple to use on a per-case basis, it doesn't actually seem like that big of a change to me. Also, the fact that GHC supports so many extensions actually gives a good path to updating the language. Since extension are enabled on a per-file basis, in most cases old libraries would just work with new-Haskell as long as the build system knows to build them in old-Haskell mode.

nightski 6y ago
I worked with Haskell for a few years and have a book on immutable data structures (Okasaki) in my book shelf here. From what I remember, with immutable data structures strict by default is actually a pretty bad default (please correct me if I remember wrong). I can only imagine this is one of the reasons Haskell is lazy by default (seriously, it's more than just that they wanted to try this crazy thing). Just enabling strictness everywhere in Haskell isn't just inherently better. Laziness is actually quite good (and the OP even says this to an extent). It's more nuanced than it seems.
- gizmo686 6y ago
  For small amounts of data, strictness is better then laziness. There is a simmilar lesson even in non-pure languages: copying small amounts of data is almost always faster than fancy scheme you want to do to avoid copying. For large amounts of data in an immutable structure, laziness is pretty much essential. The theory behind strict-by-default is that most of the time, you are not dealing with large amounts of data; even if you have pointers to large data, or pointers to pointers of large data. Even though laziness is vital to a pure language, you only need to use it in a relatively small number of places.
  - dwohnitmok 6y ago
    Wait why is laziness vital to large data structures? Even with strict functions on strict, but persistent functions, you almost never copy the entire data structure. For example a strict function on a strict persistent list that swaps the head of the list doesn't have to copy the entire tail of the list. The thing that laziness enables is short-circuiting, so e.g. a fold over the list can bail out early if necessary. But this is actually a minority of use cases for large data, since we often bound the size of data structures with something like a `take n` function for some integer n, which only processes n elements in a strict language.

massysett 6y ago

Laziness - or more precisely, non-strictness - is the essence of Haskell. Haskell was created because there were a bunch of non-strict languages out there, and folks saw a need for one non-strict language to rule them all. Often a defining feature of Haskell is thought to be its purity. Purity arose from non-strictness. Monadic IO arose from non-strictness (other solutions to IO were also tried.) This is best discussed in a paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I guess you could make Haskell strict by default...but why? It wouldn't be Haskell anymore. Non-strictness is the defining element of the language. In my view a strict-by-default Haskell is...something else. Maybe it's better for certain things. Maybe it takes things to the next level. But it isn't Haskell. Don't call it that.

rtpg 6y ago
I think what’s being proposed around “strict data fields by default” (or, an alternative or “some new concept that evokes strictness where it makes sense”) could let us continue to use Haskell and its laziness. This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.
mst 6y ago
"strict-by-default" isn't really the proposal here. Only "some things' laziness is more a footgun than a feature, maybe we should consider fixing those". The foldl/sum/product example in part one is maybe clearer about that.
cies 6y ago
I understand the historic context of laziness, and what it "brought" or "taught" us. But is it really that important now, or moving forward? I side with Snoyman in the "strict by default would probably be better". Sure it's no longer Haskell then. But could there not be a language like Haskell leveraging strict by default? Possibly even on the GHC?
- cycloptic 6y ago
  Isn't that basically every other ML variant?

3np 6y ago

Do you think there's any hope of Haskell community moving to Idris? It's years since I did either but I think Idris is just a Better Haskell without several of the issues brought up.

lupire 6y ago
For small programs, but not in general. Haskell has too many more language features and libraries.

mumblemumble 6y ago

> Can Haskell evolve? Should it? Haskell has already shown an impressive ability to evolve. Evolution is how it got where it is today. Language design analogues of the blood vessels being on the wrong side of the retina and all. If the goal remains to have an effective research language with a more-or-less unsurpassed capacity for evolution and pushing the state of the art in interesting directions, I'd say Haskell is still great just as it is. If, on the other hand, the goal is to have a productive industrial programming language that encompasses all of Haskell's great ideas, but without quite so many troublesome language warts, evolutionary vestiges, or {-# LANGUAGE EverythingInterestingThatsHappenedOverThePastThirtyYears #-}, it might be better to make a clean break.

agentultra 6y ago
GHC is a production-ready compiler (for Haskell) suited for industry use. I work on a growing, healthy team and we ship an application written in Haskell several times a day. It has decent tooling, which is improving, and the language itself is what makes it possible to tolerate the pace of those developments. Haskell isn't a pure "research-only" language. I realize people like to point out that it's original goal was research... however the nature of that research has changed over time. Take Galois' Crucible project where they used advanced dependent-types in order to write their security analysis tool [0]. They could have used research-grade dependently-typed languages that are much more expressive and easier to use... but they chose Haskell because they needed an industrial-grade compiler capable of producing fast code to run in a production setting. The kind of research being done in GHC and Haskell these days is bringing innovation and advancement in functional programming into industrial applications. Every compiler is going to have warts. Especially with people using it and depending on it for industrial use. That's a good thing. You could be like Lean 4 which will make no promises of backwards compatibility or consideration for industrial users in the name of staying purely for research. Although I agree that Haskell is impressive in its ability to evolve and grow! Linear types just landed in GHC 9.0.1 and many fine folks are improving the compiler to make way for dependent types. It's good stuff! And to see languages like Java, C#, C++, and others pick up on the low-hanging fruit of FP languages is a sign that the paradigm is gaining popularity and adoption: ADTs, lamdbas, type inference, pattern matching... Maybe in 20-30 years will see these languages adopting higher-kinded types, rank-n types, GADTs, and more? [0] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...

willtim 6y ago

IMHO Haskell is missing three features that would really improve programming in the large: 1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better. 2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules. 3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version. Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.

Ericson2314 6y ago
You realize 3 would make 1 and 2 harder or less valuable? And 3 would have also prevented a gazillion 1s and 2s from being still with us? I think breaking changes are highly underratted and people only shy away from them because the tooling expectations in all languages are so rock bottom.
- willtim 6y ago
  > You realize 3 would make 1 and 2 harder or less valuable? Yes that is why I think (1) and (2) need a new language. > And 3 would have also prevented a gazillion 1s and 2s from being still with us? I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.
  - IngoBlechschmid 6y ago
    Isn't constructing a new language the ultimate breaking change :-)

SkyMarshal 6y ago

Keep Haskell as a research language imho, but perhaps create an industrial-oriented subset of the language, similar to Ada’s SPARK [1]. Make it strict if necessary, flip whatever pragmas support an industrial use case, etc., and create a separate brand but which still references Haskell. [1]:https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language)

js8 6y ago

> Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. He mentioned https://github.com/commercialhaskell/rio https://github.com/commercialhaskell/rio in the 1st article, it's interesting, I wasn't aware of it. (I am using classy-prelude but I might try it out.)

jrochkind1 6y ago

The OP addresses your question, saying he is not advocating for removing laziness, but does have some specific suggestions. > I'm not advocating for removing laziness in Haskell. In fact I'm not really advocating for much of anything in this series. I'm just complaining, because I like complaining. > But if I was to advocate some changes: * Deprecate partial functions * Introduce a naming scheme for partial functions to be more obvious * Introduce a compiler warning to note partial function use (with a pragma to turn off specific usages) * Warn by default on partial pattern matches * Advocate strict data fields by default

colonwqbang 6y ago
Change all partial functions from returning a to returning Maybe a. Then we rename the fromJust function into the $%&!# operator (name intended to suggest the exclamation made by the programmer when function fails).
_ezkx 6y ago
If StrictData were simply made the new default (with exceptions for lists and some other things in the standard lib), I bet very little code would break. It certainly wouldn't change the flavor of the language. I think it's a good idea.

tikhonj 6y ago

Haskell needs its own Elixir: a language different enough to fix fundamental problems but similar enough to inhabit the same world. I'm imagining a language with its own frontend and some of its own features that could still reuse GHC (maybe from Core down) and share libraries freely in both directions, while also able to address some fundamental issues without being constrained by backwards compatibility. I personally love Haskell: I think it's in a great place as a language (even if it isn't wildly popular) and on a positive trajectory. But I definitely feel the same pain points Snoyman brings up, and maybe some others. (Template Haskell >.<) I don't see any way of fixing many of the biggest issues if we care about backwards-compatibility at all, and a language with 30 years of existing code can never get away from that. I also don't think te community could weather a Python 2 → 3 transformation (much less Perl 5 → 6). So the only path I see towards simultaneously keeping what's great about Haskell and improving all that isn't would be another language that can coexist simultaneously, just like Elixir and Erlang.

Kototama 6y ago
PureScript would almost fit :-). It would just need a modern Haskell backend but having a strict language built on a lazy-one is probably not the best idea :-).
- YawningAngel 6y ago
  You can avoid lazy behaviour entirely in Haskell if you want to, so your purescript to haskell compiler can just only generate contrived haskell code that doesn't exhibit laziness
- cies 6y ago
  Idris maybe? If Idris has easy interop with the Rust ecosystem, we'd have a great backend (and with wasmer possibly also fontend) option.
  - Kototama 6y ago
    I was also thinking as Rust as a backend for a FP language in the last day. I found some Ocaml binding for Rust. It would be interesting to see how it fits.

cptwunderlich 6y ago

FYI there was a proposal for a "Haskell 2021 Language" Extensions (similar to Haskell 98 and 2010), which was approved. This enables a bunch of extensions (and I guess will become default): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p... That being said, while there are alternative preludes, I'm not sure how or when (or ever) the current prelude will be changed or replaced. In terms of language evolution, the community seems to focus on further extensions of the Type System (linear types, quicklook impredicativity, dependent types), where I think there is a bigger need in better tooling. Of course, there too, lots of things are happening, like haskell-language-server, ghc-debug etc. etc. But still lots of work to do. Would be great if more people worked on modern tooling and improving GHC. And even better if more companies would fund that =)