Hacker News Reader

Comment by gizmo686 | Hacker News Reader

GHC already supports strict-by-default

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.

View on HN

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.

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.

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.

Data should be strict, logic should be lazy. It's the programmer's job do use judgment to decide which parts of which data structures are data vs logic. One heuristic is that anything recursive should be lazy, and the rest strict

    (Tree = Leaf !Int | Node [Tree]))

and if you really need a lazy int in there, delay it yourself using partially applied functions.

Yea, I agree with this and it's a good pattern in the case you know the type is "Int" or some other primitive. But Haskell thrives on type variables and data structures are usually defined generically making it more complicated.

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.

Having just read that book, it's not that laziness is bad or good for data structure performance. It's mostly that you can't use a data structure designed for one paradigm with the other and expect the same performance characteristics. Laziness can make things faster (I think the CatenableQueue was a good example of this), but it can also make things slower (take your pick of examples).

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.

Reply on news.ycombinator.com