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/...
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.
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?
The whole haskell project is about allowing programmers to write code that is declarative without making concessions for performance. Laziness makes this possible because it abstracts out evaluation order and thus allows extreme optimization by the compiler
Elm, PureScript, OCaml (Reason/ReScript) and F# did come to mind.
This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.
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.
Implicit, pervasive laziness makes performance non-compositional and more or less impossible to reason about. AIUI the largest industrial deployment of Haskell uses a strict variant for this reason.
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.
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.
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.
No not really, if your language is intentionally designed to be a foundation for other languages. So many lisps are trivially host languages for other languages at their core. Even JS is at this point, with the widespread use of Babel and various bundlers. Those languages themselves are seldom very different underneath that.
There will be two similar yet different languages in use until everyone migrates to the new version. This process could happen quickly or not at all.
Now, perhaps the problem in your eyes is the old version isn't being maintained. But I see the opposite: maintaining two versions indefinitely is the problem. The Haskell community is not infinitely big, nor growing fast enough, that if e.g. 1/2 went to Idris and 1/2 stayed, it wouldn't be catastrophic.
Making the changes we need to make, and then making it as easy as possible for everyone to migrate, I think is the best way.
How about the middle ground of marking them as deprecated and not to be used in new code?
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.
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_Dependent...
Just because you don't see a bunch of blog posts like "We rewrote our <useless product> in <language du jour>!" doesn't mean it's not being used. In fact, more serious companies tend to lean less heavily on the developer social media publicity circuit.
I have heard of Haskell used in companies mentioned by other comments, but I am surprised, pleasantly, that Starbucks uses Haskell.
Do you have a pointer (job posting, blog post, etc.) to Starbucks using Haskell? It could help me push for using Haskell by my employer, for example.
[0] https://hackage.haskell.org/package/haxl
[1] https://engineering.fb.com/2021/02/05/open-source/hsthrift/
I have heard of Haskell used in companies mentioned by other comments, but I am surprised, pleasantly, that Starbucks uses Haskell.
Do you have a pointer (job posting, blog post, etc.) to Starbucks using Haskell? It could help me push for using Haskell by my employer, for example.
it's possible to express those in C++ pretty much since templates exist.
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.
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.
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.
(Tree = Leaf !Int | Node [Tree]))
From what I remember to get around this one would use a type class to define a data structure's operations, and then provide specific implementations of that data structure for specific strict data types. But that is more complicated than just having the compiler apply strictness everywhere.
In all I guess I'm not disagreeing with you at all, I just wanted to provide a bit more context and get some more use out of that book.
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.
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.
> 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[1]:https://en.wikipedia.org/wiki/SPARK_(programming_language)
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.
`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 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 to address just these sorts of issues, and not the harder ones people confuse them with.
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.
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...
2: https://hackage.haskell.org/package/base-4.14.0.0/docs/Syste...
I don't get what you're trying to say. I never said that head was good. The discussion about head is a sidetrack to the original question, which is "To what extend can we do without [partial functions]?", and to which my answer is "we can't do without". head is not a good example of a partial function, and its existence doesn't conflict with the idea that good partial functions are a necessary part of the language.
He mentioned 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.)
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 =)
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...