Hacker News Reader

Comment by Scarbutt | Hacker News Reader

Wasn't laziness one of the things Haskell would ditch if it were to start from zero? Why is neohaskell keeping it?

Depends on what you mean by 'start from zero'. Haskell was born as a design by committee research language to serve as a platform for answering various questions in programming language research, including a lot of questions about the effectiveness of laziness. As such Haskell without laziness would not be fit for purpose.

Some people on the other hand want to say that the research part is 'done' and that Haskell should move on and become just another language suitable for use in industry and production. And some of those people think that laziness should be relaxed.

And some people think laziness is still good and a desire-able property [0].

tldr; laziness enables a lot of optimizations for high-level languages that are good for performance. Laziness/strictness aren't direct causes for performance but impact it in different ways. There are a lot of myths around thunks and memory usage. There are still fertile areas for improvement.

Haskell is suitable for industrial use and production. Most of the research being done these days is around maintaining an industrial-grade compiler pipeline while supporting new, interesting features [1]. And it has been that way for quite a long time now.

[0] https://www.youtube.com/watch?v=fSqE-HSh_NU

[1] https://www.researchgate.net/publication/334751646_Dependent...

The most fundamental proposition of Haskell was essentially the research question, "how lazy can we make a programming language?", it's the standout feature, so that'd seem kind of weird.

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16...

In case someone wants to know what that paper is without having to download it:

- "A history of Haskell: being lazy with class", from 2007, by Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler.

- https://doi.org/10.1145/1238844.1238856

You should probably also read "Wearing the hair shirt" (2003).

https://www.microsoft.com/en-us/research/publication/wearing...

I don't think so. There would probably be changes to which things are lazy by default (like enabling StrictData by default). For an in-depth explanation see this youtube playlist (currently 4 videos): https://youtube.com/playlist?list=PLyzwHTVJlRc8620PjqbM0x435...

The quip is something like "The next Haskell should be strict and the next ML should be pure".

I think the overall outlook in PL research is that the "next Haskell" should abstract away altogether from the whole strict/lazy distinction by treating both 'strictness' and 'laziness' on a first-class basis, leveraging ideas such as polarity, focusing and call-by-push-value.

This would essentially make 'data' types strict by default and 'codata' types lazy by default, but with easy syntax to add laziness or strictness after the fact. And some types (tuples, functions) would exist in both 'data' (strict by default) and 'codata' (lazy by default) flavors.

> make 'data' types strict by default and 'codata' types lazy by default

Coq has been doing exactly this for over a decade...

Reply on news.ycombinator.com