<div dir="ltr"><div>I think this is a very good idea. Non-strict `foldl` for summing and multiplying introduces undesired space leaking behavior and is a very surprising default both to beginners and even for more experienced Haskellers.<br></div><div><br></div><div>If there was a Num type with lazy structure, something like `product [<some_list_containing_zero>] == 0` would be able to short-circuit as soon as it hits a zero. However since none of the Num types in base have a lazy structure (and both sum and product have a Num constraint), there is not really a way to take advantage of laziness anyway and therefore the best implementation would be Olegs option A.<br></div><div><br></div><div>Best regards,</div><div>Wander<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op zo 18 okt. 2020 om 20:14 schreef Hécate <<a href="mailto:hecate@glitchbra.in">hecate@glitchbra.in</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My fellow Haskell developers, contributors and maintainers,<br>
<br>
I wish to present what is certainly a controversial proposal for the<br>
`base` library:<br>
    Making the `sum` and `product` functions from the `base` library strict.<br>
<br>
This is not a new question, the debate is old, but I am personally <br>
convinced that the existence of those two lazy functions is something <br>
that should never have happened.<br>
One of the first goals that led to the creation of Haskell was to enable <br>
collaboration and research in the domain of lazy (or non-strict) <br>
programming languages and techniques.<br>
While it led to the discovery of new methods and ways to represent <br>
programs, we also realised that this paradigm has proven to produce <br>
sub-optimal implementations for<br>
these functions.<br>
<br>
And while maintaining backward compatibility *is* important when <br>
designing and maintaining a programming language, we have thankfully <br>
developed deprecation mechanisms<br>
that can be used to signal that bad, or sub-optimal decisions of the <br>
past can be corrected.<br>
<br>
To refresh our collective memory, here is the current state of things, <br>
regarding `sum`:<br>
<br>
```<br>
❯ ghci +RTS -M1024m<br>
GHCi, version 8.10.1: <a href="https://www.haskell.org/ghc/" rel="noreferrer" target="_blank">https://www.haskell.org/ghc/</a>  :? for help<br>
λ❯ sum [1..10^9]<br>
*** Exception: heap overflow<br>
```<br>
Whereas, with an alternative implementation, such as `foldl'`:<br>
```<br>
λ❯ foldl' (+) 0 [1..10^9]<br>
500000000500000000<br>
(31.35 secs, 88,000,076,288 bytes)<br>
```<br>
<br>
I do not think a heap overflow, and the underlying space leak occasioned <br>
by the laziness of `foldl`, are behaviours we should aim to preserve for <br>
the sake of backward compatibility.<br>
<br>
And actually, I think that moving these two functions to a strict, space <br>
leak-free implementation would benefit the lazy PL research domain by <br>
showing a good counter-example<br>
of why it is not necessarily suitable for every kind of computation.<br>
I also think, and this is rooted from experience, that we must strive to <br>
empower our users with the power of laziness. Not burden them with it.<br>
Standing on the shoulders of giants is what made Haskell so great, but <br>
this should not prevent us from spreading our wings to go higher.<br>
<br>
———<br>
<br>
Now, there have been Prelude replacements (such as Relude) and companion <br>
libraries (like `strict`) who have been shipping such alternative <br>
implementations for quite some time now.<br>
<br>
A point that can be raised is: Why should we bother? Isn't `strict` <br>
already enough?<br>
To this I answer: `strict` and Relude, ultimately, patches on an tire's <br>
inner tube. We may be able to roll with them for some distance, but <br>
their very existence is a response to an abnormal situation that we have <br>
grown to accept.<br>
However, any bicycle rider who has the means to change their tire should <br>
do so.<br>
I believe we have the means to do so.<br>
<br>
Another point that could be raised as well is the fact that this <br>
implementation change would deviate from the 2010 Haskell Report[0].<br>
If we want to stay true to the spirit and letter of the Report, this is <br>
actually a non-issue. Indeed, it is noted that:<br>
<br>
> This  report  defines  the  syntax  for Haskell  programs and  an <br>
informal  abstract  semantics  for  the  meaning of such programs.  We <br>
leave as implementation dependent the ways in which Haskell programs are <br>
to be manipulated, interpreted, compiled, etc. This includes such issues <br>
as the nature of programming environments and the error messages <br>
returned for undefined programs (i.e. programs that formally evaluate <br>
to⊥).[1]<br>
<br>
As well as in chapter 9:<br>
<br>
> In this chapter the entire Haskell Prelude is given. It constitutes a <br>
specification for the Prelude. Many of the definitions are written with <br>
clarity rather than efficiency in mind, and it is not required that the <br>
specification be implemented as shown here.[2]<br>
<br>
And finally, regarding the non-strict nature of Haskell, the Report <br>
references strict evaluation to avoid "unneeded laziness."[3]<br>
Thus it was expected that laziness would not be a silver bullet, and it <br>
could harm performance.<br>
<br>
———<br>
<br>
Regarding the implementation detail, `sum` and `product` would <br>
piggy-back on the already-present `foldMap'` function.<br>
<br>
<br>
Thank you very much for reading,<br>
I believe we can all go together towards improving the experience of <br>
Haskell developers, starting with this.<br>
<br>
[0]: Haskell 2010 Language Report, <br>
<a href="https://www.haskell.org/definition/haskell2010.pdf" rel="noreferrer" target="_blank">https://www.haskell.org/definition/haskell2010.pdf</a><br>
[1]: Haskell 2010 Language Report, page 3<br>
[2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105<br>
[3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75<br>
<br>
-- <br>
Hécate ✨<br>
IRC: Uniaika<br>
WWW: <a href="https://glitchbra.in" rel="noreferrer" target="_blank">https://glitchbra.in</a><br>
RUN: BSD<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>