5 ms·

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

ctenb 3y ago
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-6-Gi1Gu&si=d0eFuwwtBW1V2ZFU https://youtube.com/playlist?list=PLyzwHTVJlRc8620PjqbM0x435...
Barrin92 3y ago
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.168.4008&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16...
- luispauloml 3y ago
  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 https://doi.org/10.1145/1238844.1238856
  - throwaway81523 3y ago
    You should probably also read "Wearing the hair shirt" (2003). https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing...
dagw 3y ago
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.
- agentultra 3y ago
  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 https://www.youtube.com/watch?v=fSqE-HSh_NU [1] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...
frou_dh 3y ago
The quip is something like "The next Haskell should be strict and the next ML should be pure".
- zozbot234 3y ago
  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.
  - KirillPanov 3y ago
    > make 'data' types strict by default and 'codata' types lazy by default Coq has been doing exactly this for over a decade...

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-6-Gi1Gu&si=d0eFuwwtBW1V2ZFU https://youtube.com/playlist?list=PLyzwHTVJlRc8620PjqbM0x435...

Barrin92 3y ago

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.168.4008&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16...

luispauloml 3y ago
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 https://doi.org/10.1145/1238844.1238856
- throwaway81523 3y ago
  You should probably also read "Wearing the hair shirt" (2003). https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing...

dagw 3y ago

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.

agentultra 3y ago
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 https://www.youtube.com/watch?v=fSqE-HSh_NU [1] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...

frou_dh 3y ago

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

zozbot234 3y ago
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.
- KirillPanov 3y ago
  > make 'data' types strict by default and 'codata' types lazy by default Coq has been doing exactly this for over a decade...