Hacker News Reader

Comment by massysett | Hacker News Reader

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/...

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.

View on HN

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?

Making Haskell strict-by-default would also break the rewrite engine which is the core of Haskell's high performance with functional combinators.

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

I don't see how the rewrite engine would break if Haskell would be strict. Can you expand on that?

Idris for instance is strict "by default" but still supports laziness through the Lazy data type.

Forgot about Idris.

Elm, PureScript, OCaml (Reason/ReScript) and F# did come to mind.

Isn't that basically every other ML variant?

Not exactly. Syntax-aside, MLs in general: have better module systems than Haskell, no typeclasses, and aren’t pure.

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.

"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.

But once you have purity you don't need strictness - Idris takes that approach.

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.

Reply on news.ycombinator.com