From david.feuer at gmail.com Fri Oct 2 00:37:07 2020 From: david.feuer at gmail.com (David Feuer) Date: Thu, 1 Oct 2020 20:37:07 -0400 Subject: How the heck should we fix Ord for Array? Message-ID: At present, the Eq instance for Data.Array.Array is somewhat broken[1]. In particular, it ignores the array bounds for empty arrays (but not for other arrays), so its meaning is inconsistent, and the bounds function doesn't respect ==. The fix to that is tiny and obvious: pay attention to the bounds regardless. Eq and Ord instances are expected to be compatible: a == b <==> compare a b = EQ So when I started putting together a merge request to fix the Eq instance, I glanced over at the Ord instance to see what that was doing. That instance was 1. Incompatible with the current Eq instance. 2. Incompatible with the proposed Eq instance. Specifically, that instance compares the association lists of the two arrays, ignoring the bounds in all cases. It is not at all obvious to me what the Ord instance should actually be, except that it should be compatible with Eq. [1] https://gitlab.haskell.org/ghc/ghc/-/issues/18700 From pi.boy.travis at gmail.com Fri Oct 2 06:52:31 2020 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Thu, 1 Oct 2020 23:52:31 -0700 Subject: llvm-hs version 10, and library maintainers Message-ID: Hello fellow Haskellers, LLVM version 10 is out, and LLVM 11 is on the way. I'm curious if anyone has begun work on getting llvm-hs working with version 10. This is likely to be a bit more of a chore than usual, because of changes in the JIT API. Furthermore, activity on the llvm-hs GitHub repo seems to have slowed; I'm curious who the current maintainers are and whether or not they could use a hand? I make active use of the package and would be happy to contribute time to help out any way I can. Thanks, Travis Whitaker From lemming at henning-thielemann.de Fri Oct 2 09:43:11 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 2 Oct 2020 11:43:11 +0200 (CEST) Subject: llvm-hs version 10, and library maintainers In-Reply-To: References: Message-ID: Hi Travis, On Thu, 1 Oct 2020, Travis Whitaker wrote: > LLVM version 10 is out, and LLVM 11 is on the way. I'm curious if > anyone has begun work on getting llvm-hs working with version 10. This > is likely to be a bit more of a chore than usual, because of changes > in the JIT API. > > Furthermore, activity on the llvm-hs GitHub repo seems to have slowed; > I'm curious who the current maintainers are and whether or not they > could use a hand? I make active use of the package and would be happy > to contribute time to help out any way I can. I continue to maintain the other LLVM wrapper, based on the original llvm package by O'Sullivan and Augustsson: https://hackage.haskell.org/package/llvm-tf https://hackage.haskell.org/package/llvm-ffi However, I also support only up to LLVM-9 for now. Updating the Haskell bindings is tedious because LLVM changes details often and the changes are hardly documented. On the other hand, I have long-standing problems with LLVM. E.g. when I start optimizing via LLVM's C interface the result is much worse than the one produced by the opt command-line utility. I would like to know, whether llvm-hs has this problem, too. However, I miss a simple example for demonstration. From david.feuer at gmail.com Mon Oct 12 18:01:30 2020 From: david.feuer at gmail.com (David Feuer) Date: Mon, 12 Oct 2020 14:01:30 -0400 Subject: Use of evaluate in Control.Concurrent.MVar Message-ID: Control.Concurrent.MVar uses `evaluate` in a couple places, and I don't understand why: modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a putMVar m a' return b modifyMVarMasked :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVarMasked m io = mask_ $ do a <- takeMVar m (a',b) <- (io a >>= evaluate) `onException` putMVar m a putMVar m a' return b The general purpose is to make sure that the result of the IO action is forced to head normal form within the scope of the `catch` block created by `onException`. But in this context, I don't see why we need to use `evaluate` rather than just `seq`, or why that is desirable. Couldn't we just do this? modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a >>= (pure $!)) `onException` putMVar m a putMVar m a' return b David From roma at ro-che.info Mon Oct 12 18:20:12 2020 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 12 Oct 2020 21:20:12 +0300 Subject: Use of evaluate in Control.Concurrent.MVar In-Reply-To: References: Message-ID: <1d1e9b70-8610-4a88-3231-b2886308b6af@ro-che.info> Hi David, On 12/10/2020 21.01, David Feuer wrote: > Couldn't we just do this? > > modifyMVar m io = > mask $ \restore -> do > a <- takeMVar m > (a',b) <- restore (io a >>= (pure $!)) `onException` putMVar m a > putMVar m a' > return b No — the haddocks for 'evaluate' in Control.Exception explain the difference between the two. In particular, > The rule of thumb is to use evaluate to force or handle exceptions in lazy values. If, on the other hand, you are forcing a lazy value for efficiency reasons only and do not care about exceptions, you may use return $! x. If you want to know why, I think you can find some old bugs in the ghc bug tracker that resulted from an incorrect usage of return $! ... where evaluate was warranted. Roman From david.feuer at gmail.com Mon Oct 12 19:23:07 2020 From: david.feuer at gmail.com (David Feuer) Date: Mon, 12 Oct 2020 15:23:07 -0400 Subject: Use of evaluate in Control.Concurrent.MVar In-Reply-To: <1d1e9b70-8610-4a88-3231-b2886308b6af@ro-che.info> References: <1d1e9b70-8610-4a88-3231-b2886308b6af@ro-che.info> Message-ID: Yes, I generally understand that; I just don't *think* it applies here. The issue with `seq` tends to be that strictness information can propagate "back in time", or forcing can be delayed, etc. I just don't immediately see that as an issue in this *particular* spot. That said, I imagine that in many cases the compiler will see that the pair is surely produced, in which case the `evaluate` will go away. On Mon, Oct 12, 2020 at 2:20 PM Roman Cheplyaka wrote: > > Hi David, > > On 12/10/2020 21.01, David Feuer wrote: > > Couldn't we just do this? > > > > modifyMVar m io = > > mask $ \restore -> do > > a <- takeMVar m > > (a',b) <- restore (io a >>= (pure $!)) `onException` putMVar m a > > putMVar m a' > > return b > > No — the haddocks for 'evaluate' in Control.Exception explain the difference between the two. In particular, > > > The rule of thumb is to use evaluate to force or handle exceptions in lazy values. If, on the other hand, you are forcing a lazy value for efficiency reasons only and do not care about exceptions, you may use return $! x. > > If you want to know why, I think you can find some old bugs in the ghc bug tracker that resulted from an incorrect usage of return $! ... where evaluate was warranted. > > Roman > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From vladislav at serokell.io Mon Oct 12 23:04:31 2020 From: vladislav at serokell.io (Vladislav Zavialov) Date: Tue, 13 Oct 2020 02:04:31 +0300 Subject: Version bump in 'unix' and 'parsec' Message-ID: <640F9FD5-9E4E-4489-96F4-B1B0F7329DDD@serokell.io> Three weeks ago I sent 10 pull requests to GHC boot libraries, bumping the upper bound on ‘base’ to accept base-4.16, for the next GHC release. Most of these were merged, but two remain: 1. https://github.com/haskell/unix/pull/158 2. https://github.com/haskell/parsec/pull/118 Could somebody with the permissions hit the merge button? It’s just a version bump and I need it to unblock some other work. - Vlad From hecate at glitchbra.in Sun Oct 18 18:13:33 2020 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sun, 18 Oct 2020 20:13:33 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: Message-ID: My fellow Haskell developers, contributors and maintainers, I wish to present what is certainly a controversial proposal for the `base` library:    Making the `sum` and `product` functions from the `base` library strict. This is not a new question, the debate is old, but I am personally convinced that the existence of those two lazy functions is something that should never have happened. One of the first goals that led to the creation of Haskell was to enable collaboration and research in the domain of lazy (or non-strict) programming languages and techniques. While it led to the discovery of new methods and ways to represent programs, we also realised that this paradigm has proven to produce sub-optimal implementations for these functions. And while maintaining backward compatibility *is* important when designing and maintaining a programming language, we have thankfully developed deprecation mechanisms that can be used to signal that bad, or sub-optimal decisions of the past can be corrected. To refresh our collective memory, here is the current state of things, regarding `sum`: ``` ❯ ghci +RTS -M1024m GHCi, version 8.10.1: https://www.haskell.org/ghc/  :? for help λ❯ sum [1..10^9] *** Exception: heap overflow ``` Whereas, with an alternative implementation, such as `foldl'`: ``` λ❯ foldl' (+) 0 [1..10^9] 500000000500000000 (31.35 secs, 88,000,076,288 bytes) ``` I do not think a heap overflow, and the underlying space leak occasioned by the laziness of `foldl`, are behaviours we should aim to preserve for the sake of backward compatibility. And actually, I think that moving these two functions to a strict, space leak-free implementation would benefit the lazy PL research domain by showing a good counter-example of why it is not necessarily suitable for every kind of computation. I also think, and this is rooted from experience, that we must strive to empower our users with the power of laziness. Not burden them with it. Standing on the shoulders of giants is what made Haskell so great, but this should not prevent us from spreading our wings to go higher. ——— Now, there have been Prelude replacements (such as Relude) and companion libraries (like `strict`) who have been shipping such alternative implementations for quite some time now. A point that can be raised is: Why should we bother? Isn't `strict` already enough? To this I answer: `strict` and Relude, ultimately, patches on an tire's inner tube. We may be able to roll with them for some distance, but their very existence is a response to an abnormal situation that we have grown to accept. However, any bicycle rider who has the means to change their tire should do so. I believe we have the means to do so. Another point that could be raised as well is the fact that this implementation change would deviate from the 2010 Haskell Report[0]. If we want to stay true to the spirit and letter of the Report, this is actually a non-issue. Indeed, it is noted that: > This  report  defines  the  syntax  for Haskell  programs and  an informal  abstract  semantics  for  the  meaning of such programs.  We leave as implementation dependent the ways in which Haskell programs are to be manipulated, interpreted, compiled, etc. This includes such issues as the nature of programming environments and the error messages returned for undefined programs (i.e. programs that formally evaluate to⊥).[1] As well as in chapter 9: > In this chapter the entire Haskell Prelude is given. It constitutes a specification for the Prelude. Many of the definitions are written with clarity rather than efficiency in mind, and it is not required that the specification be implemented as shown here.[2] And finally, regarding the non-strict nature of Haskell, the Report references strict evaluation to avoid "unneeded laziness."[3] Thus it was expected that laziness would not be a silver bullet, and it could harm performance. ——— Regarding the implementation detail, `sum` and `product` would piggy-back on the already-present `foldMap'` function. Thank you very much for reading, I believe we can all go together towards improving the experience of Haskell developers, starting with this. [0]: Haskell 2010 Language Report, https://www.haskell.org/definition/haskell2010.pdf [1]: Haskell 2010 Language Report, page 3 [2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105 [3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75 -- Hécate ✨ IRC: Uniaika WWW: https://glitchbra.in RUN: BSD From vamchale at gmail.com Sun Oct 18 18:46:34 2020 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 18 Oct 2020 13:46:34 -0500 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: Message-ID: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> For my own edification, what happens in actual code? i.e. not GHCi Cheers, Vanessa McHale On 10/18/20 1:13 PM, Hécate wrote: > My fellow Haskell developers, contributors and maintainers, > > I wish to present what is certainly a controversial proposal for the > `base` library: >    Making the `sum` and `product` functions from the `base` library > strict. > > This is not a new question, the debate is old, but I am personally > convinced that the existence of those two lazy functions is something > that should never have happened. > One of the first goals that led to the creation of Haskell was to > enable collaboration and research in the domain of lazy (or > non-strict) programming languages and techniques. > While it led to the discovery of new methods and ways to represent > programs, we also realised that this paradigm has proven to produce > sub-optimal implementations for > these functions. > > And while maintaining backward compatibility *is* important when > designing and maintaining a programming language, we have thankfully > developed deprecation mechanisms > that can be used to signal that bad, or sub-optimal decisions of the > past can be corrected. > > To refresh our collective memory, here is the current state of things, > regarding `sum`: > > ``` > ❯ ghci +RTS -M1024m > GHCi, version 8.10.1: https://www.haskell.org/ghc/  :? for help > λ❯ sum [1..10^9] > *** Exception: heap overflow > ``` > Whereas, with an alternative implementation, such as `foldl'`: > ``` > λ❯ foldl' (+) 0 [1..10^9] > 500000000500000000 > (31.35 secs, 88,000,076,288 bytes) > ``` > > I do not think a heap overflow, and the underlying space leak > occasioned by the laziness of `foldl`, are behaviours we should aim to > preserve for the sake of backward compatibility. > > And actually, I think that moving these two functions to a strict, > space leak-free implementation would benefit the lazy PL research > domain by showing a good counter-example > of why it is not necessarily suitable for every kind of computation. > I also think, and this is rooted from experience, that we must strive > to empower our users with the power of laziness. Not burden them with it. > Standing on the shoulders of giants is what made Haskell so great, but > this should not prevent us from spreading our wings to go higher. > > ——— > > Now, there have been Prelude replacements (such as Relude) and > companion libraries (like `strict`) who have been shipping such > alternative implementations for quite some time now. > > A point that can be raised is: Why should we bother? Isn't `strict` > already enough? > To this I answer: `strict` and Relude, ultimately, patches on an > tire's inner tube. We may be able to roll with them for some distance, > but their very existence is a response to an abnormal situation that > we have grown to accept. > However, any bicycle rider who has the means to change their tire > should do so. > I believe we have the means to do so. > > Another point that could be raised as well is the fact that this > implementation change would deviate from the 2010 Haskell Report[0]. > If we want to stay true to the spirit and letter of the Report, this > is actually a non-issue. Indeed, it is noted that: > >> This  report  defines  the  syntax  for Haskell  programs and  an > informal  abstract  semantics  for  the  meaning of such programs.  We > leave as implementation dependent the ways in which Haskell programs > are to be manipulated, interpreted, compiled, etc. This includes such > issues as the nature of programming environments and the error > messages returned for undefined programs (i.e. programs that formally > evaluate to⊥).[1] > > As well as in chapter 9: > >> In this chapter the entire Haskell Prelude is given. It constitutes a > specification for the Prelude. Many of the definitions are written > with clarity rather than efficiency in mind, and it is not required > that the specification be implemented as shown here.[2] > > And finally, regarding the non-strict nature of Haskell, the Report > references strict evaluation to avoid "unneeded laziness."[3] > Thus it was expected that laziness would not be a silver bullet, and > it could harm performance. > > ——— > > Regarding the implementation detail, `sum` and `product` would > piggy-back on the already-present `foldMap'` function. > > > Thank you very much for reading, > I believe we can all go together towards improving the experience of > Haskell developers, starting with this. > > [0]: Haskell 2010 Language Report, > https://www.haskell.org/definition/haskell2010.pdf > [1]: Haskell 2010 Language Report, page 3 > [2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105 > [3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From hecate at glitchbra.in Sun Oct 18 19:17:43 2020 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sun, 18 Oct 2020 21:17:43 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> Message-ID: Hi Vanessa, thanks for the question. I compiled the following code: ``` module Main where main = do   let result = sum [1..10^9]   print result ``` with the following command: ghc -rtsopts -On --make Main.hs and ran the binary like that: ./Main +RTS -M1024m -RTS Compiled with -O0, the heap overflows Starting with -O1, it runs fine. However: I am not able to tell you what kind of optimisation is responsible for this, and to be quite honest, I don't see why we should trust the optimiser to produce behaviours that could be upstreamed; behaviour that  is enabled at the first sign of optimisation. I am not fundamentally opposed to the concept of having neat optimisations in GHC, but experience tells me that 1. They can (and will) regress 2. They can (and will) interact in weird ways 3. This naked call gets optimised, that's great, but how will it react with other Foldables, with fusion, etc? In conclusion, leaving things to the optimiser that could be trivially made fast every time seems needlessly risky. Cheers! On 18/10/2020 20:46, Vanessa McHale wrote: > For my own edification, what happens in actual code? i.e. not GHCi > > Cheers, > Vanessa McHale > > On 10/18/20 1:13 PM, Hécate wrote: >> My fellow Haskell developers, contributors and maintainers, >> >> I wish to present what is certainly a controversial proposal for the >> `base` library: >>    Making the `sum` and `product` functions from the `base` library >> strict. >> >> This is not a new question, the debate is old, but I am personally >> convinced that the existence of those two lazy functions is something >> that should never have happened. >> One of the first goals that led to the creation of Haskell was to >> enable collaboration and research in the domain of lazy (or >> non-strict) programming languages and techniques. >> While it led to the discovery of new methods and ways to represent >> programs, we also realised that this paradigm has proven to produce >> sub-optimal implementations for >> these functions. >> >> And while maintaining backward compatibility *is* important when >> designing and maintaining a programming language, we have thankfully >> developed deprecation mechanisms >> that can be used to signal that bad, or sub-optimal decisions of the >> past can be corrected. >> >> To refresh our collective memory, here is the current state of things, >> regarding `sum`: >> >> ``` >> ❯ ghci +RTS -M1024m >> GHCi, version 8.10.1: https://www.haskell.org/ghc/  :? for help >> λ❯ sum [1..10^9] >> *** Exception: heap overflow >> ``` >> Whereas, with an alternative implementation, such as `foldl'`: >> ``` >> λ❯ foldl' (+) 0 [1..10^9] >> 500000000500000000 >> (31.35 secs, 88,000,076,288 bytes) >> ``` >> >> I do not think a heap overflow, and the underlying space leak >> occasioned by the laziness of `foldl`, are behaviours we should aim to >> preserve for the sake of backward compatibility. >> >> And actually, I think that moving these two functions to a strict, >> space leak-free implementation would benefit the lazy PL research >> domain by showing a good counter-example >> of why it is not necessarily suitable for every kind of computation. >> I also think, and this is rooted from experience, that we must strive >> to empower our users with the power of laziness. Not burden them with it. >> Standing on the shoulders of giants is what made Haskell so great, but >> this should not prevent us from spreading our wings to go higher. >> >> ——— >> >> Now, there have been Prelude replacements (such as Relude) and >> companion libraries (like `strict`) who have been shipping such >> alternative implementations for quite some time now. >> >> A point that can be raised is: Why should we bother? Isn't `strict` >> already enough? >> To this I answer: `strict` and Relude, ultimately, patches on an >> tire's inner tube. We may be able to roll with them for some distance, >> but their very existence is a response to an abnormal situation that >> we have grown to accept. >> However, any bicycle rider who has the means to change their tire >> should do so. >> I believe we have the means to do so. >> >> Another point that could be raised as well is the fact that this >> implementation change would deviate from the 2010 Haskell Report[0]. >> If we want to stay true to the spirit and letter of the Report, this >> is actually a non-issue. Indeed, it is noted that: >> >>> This  report  defines  the  syntax  for Haskell  programs and  an >> informal  abstract  semantics  for  the  meaning of such programs.  We >> leave as implementation dependent the ways in which Haskell programs >> are to be manipulated, interpreted, compiled, etc. This includes such >> issues as the nature of programming environments and the error >> messages returned for undefined programs (i.e. programs that formally >> evaluate to⊥).[1] >> >> As well as in chapter 9: >> >>> In this chapter the entire Haskell Prelude is given. It constitutes a >> specification for the Prelude. Many of the definitions are written >> with clarity rather than efficiency in mind, and it is not required >> that the specification be implemented as shown here.[2] >> >> And finally, regarding the non-strict nature of Haskell, the Report >> references strict evaluation to avoid "unneeded laziness."[3] >> Thus it was expected that laziness would not be a silver bullet, and >> it could harm performance. >> >> ——— >> >> Regarding the implementation detail, `sum` and `product` would >> piggy-back on the already-present `foldMap'` function. >> >> >> Thank you very much for reading, >> I believe we can all go together towards improving the experience of >> Haskell developers, starting with this. >> >> [0]: Haskell 2010 Language Report, >> https://www.haskell.org/definition/haskell2010.pdf >> [1]: Haskell 2010 Language Report, page 3 >> [2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105 >> [3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75 >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Hécate ✨ IRC: Uniaika WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Oct 18 19:24:53 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 18 Oct 2020 21:24:53 +0200 (CEST) Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> Message-ID: On Sun, 18 Oct 2020, Hécate wrote: > In conclusion, leaving things to the optimiser that could be trivially > made fast every time seems needlessly risky. `seq` is still a hack. A strict 'sum' and 'product' would still fail on a lazy accumulator type, say a lazy pair type. If at all, sum and product should be deepseq-strict. So currently, letting the optimiser make a lazy sum strict is still the smaller hack. From oleg.grenrus at iki.fi Sun Oct 18 19:49:05 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 18 Oct 2020 22:49:05 +0300 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> Message-ID: The problem is the current definition of sum for lists which uses foldl, i.e non-strict left fold     sum = foldl (+) 0 It's utterly broken. Either we should change it to foldl' to work on some types where addition is strict, Option A:     sum = foldl' (+) 0 or alternatively (to make people using lazy accumulator types), Option B:     sum = foldr (+) 0 The current state is no good for anyone or anything. --- Related issue which Hecate didn't clearly mention, is that Foldable class default implementation has    class Foldable f where        ...        sum = getSum . foldMap Sum -- this is "good" lazy definition If we select option A, then I argue that for consistency the default `Foldable.sum` should be        sum = getSum . foldMap' Sum -- strict foldMap' If we select option B, Foldable definition doesn't need to be changed. --- I repeat, using non-strict left fold, foldl, for sum and product is not good for anything. Either foldr or foldl'. I have no strong preference. Current state is unacceptable. -  Oleg On 18.10.2020 22.24, Henning Thielemann wrote: > > On Sun, 18 Oct 2020, Hécate wrote: > >> In conclusion, leaving things to the optimiser that could be >> trivially made fast every time seems needlessly risky. > > `seq` is still a hack. A strict 'sum' and 'product' would still fail > on a lazy accumulator type, say a lazy pair type. If at all, sum and > product should be deepseq-strict. So currently, letting the optimiser > make a lazy sum strict is still the smaller hack. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Sun Oct 18 19:54:33 2020 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 18 Oct 2020 14:54:33 -0500 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> Message-ID: It's sum = getSum #. foldMap Sum in base. On 10/18/20 2:49 PM, Oleg Grenrus wrote: > > The problem is the current definition of sum for lists which uses > foldl, i.e non-strict left fold > >     sum = foldl (+) 0 > > It's utterly broken. Either we should change it to foldl' to work on > some types where addition is strict, Option A: > >     sum = foldl' (+) 0 > > or alternatively (to make people using lazy accumulator types), Option B: > >     sum = foldr (+) 0 > > The current state is no good for anyone or anything. > > --- > > Related issue which Hecate didn't clearly mention, is that Foldable > class default implementation has > >    class Foldable f where >        ... >        sum = getSum . foldMap Sum -- this is "good" lazy definition > > If we select option A, then I argue that for consistency the default > `Foldable.sum` should be > >        sum = getSum . foldMap' Sum -- strict foldMap' > > If we select option B, Foldable definition doesn't need to be changed. > > --- > > I repeat, using non-strict left fold, foldl, for sum and product is > not good for anything. > Either foldr or foldl'. > > I have no strong preference. Current state is unacceptable. > > -  Oleg > > On 18.10.2020 22.24, Henning Thielemann wrote: >> >> On Sun, 18 Oct 2020, Hécate wrote: >> >>> In conclusion, leaving things to the optimiser that could be >>> trivially made fast every time seems needlessly risky. >> >> `seq` is still a hack. A strict 'sum' and 'product' would still fail >> on a lazy accumulator type, say a lazy pair type. If at all, sum and >> product should be deepseq-strict. So currently, letting the optimiser >> make a lazy sum strict is still the smaller hack. >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From oleg.grenrus at iki.fi Sun Oct 18 20:04:58 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 18 Oct 2020 23:04:58 +0300 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> Message-ID: <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> For the sake of bigger audience I didn't bother mentioning #. which is a coercion helper. It's essentially better (.) when the first argument is newtype constructor (i.e. coerce). So with Option A (strict):     sum = getSum #. foldMap' Sum Or Option B (lazy)     sum = getSum #. foldMap Sum --- There is also third option, Option C:     sum  = foldr  (+) 0     sum' = foldl' (+) 0 I don't think this is worthwhile, but it is an option. (to rehash, I don't consider maintaining status quo to be an option at all). - Oleg On 18.10.2020 22.54, Vanessa McHale wrote: > > It's > > sum = getSum #. foldMap Sum > > in base. > > On 10/18/20 2:49 PM, Oleg Grenrus wrote: >> >> The problem is the current definition of sum for lists which uses >> foldl, i.e non-strict left fold >> >>     sum = foldl (+) 0 >> >> It's utterly broken. Either we should change it to foldl' to work on >> some types where addition is strict, Option A: >> >>     sum = foldl' (+) 0 >> >> or alternatively (to make people using lazy accumulator types), Option B: >> >>     sum = foldr (+) 0 >> >> The current state is no good for anyone or anything. >> >> --- >> >> Related issue which Hecate didn't clearly mention, is that Foldable >> class default implementation has >> >>    class Foldable f where >>        ... >>        sum = getSum . foldMap Sum -- this is "good" lazy definition >> >> If we select option A, then I argue that for consistency the default >> `Foldable.sum` should be >> >>        sum = getSum . foldMap' Sum -- strict foldMap' >> >> If we select option B, Foldable definition doesn't need to be changed. >> >> --- >> >> I repeat, using non-strict left fold, foldl, for sum and product is >> not good for anything. >> Either foldr or foldl'. >> >> I have no strong preference. Current state is unacceptable. >> >> -  Oleg >> >> On 18.10.2020 22.24, Henning Thielemann wrote: >>> >>> On Sun, 18 Oct 2020, Hécate wrote: >>> >>>> In conclusion, leaving things to the optimiser that could be >>>> trivially made fast every time seems needlessly risky. >>> >>> `seq` is still a hack. A strict 'sum' and 'product' would still fail >>> on a lazy accumulator type, say a lazy pair type. If at all, sum and >>> product should be deepseq-strict. So currently, letting the >>> optimiser make a lazy sum strict is still the smaller hack. >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Sun Oct 18 20:11:09 2020 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sun, 18 Oct 2020 22:11:09 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> Message-ID: <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> Indeed, and I initially went to suggest a `foldMap'`-based implementation to keep with the current implementation of many Foldable functions that are based on `foldMap` rather than a raw `fold`. On 18/10/2020 22:04, Oleg Grenrus wrote: > For the sake of bigger audience I didn't bother mentioning #. which is > a coercion helper. It's essentially better (.) when the first argument > is newtype constructor (i.e. coerce). > > So with Option A (strict): > >     sum = getSum #. foldMap' Sum > > Or Option B (lazy) > >     sum = getSum #. foldMap Sum > > --- > > There is also third option, Option C: > >     sum  = foldr  (+) 0 >     sum' = foldl' (+) 0 > > I don't think this is worthwhile, but it is an option. > (to rehash, I don't consider maintaining status quo to be an option at > all). > > - Oleg > On 18.10.2020 22.54, Vanessa McHale wrote: >> >> It's >> >> sum = getSum #. foldMap Sum >> >> in base. >> >> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>> >>> The problem is the current definition of sum for lists which uses >>> foldl, i.e non-strict left fold >>> >>>     sum = foldl (+) 0 >>> >>> It's utterly broken. Either we should change it to foldl' to work on >>> some types where addition is strict, Option A: >>> >>>     sum = foldl' (+) 0 >>> >>> or alternatively (to make people using lazy accumulator types), >>> Option B: >>> >>>     sum = foldr (+) 0 >>> >>> The current state is no good for anyone or anything. >>> >>> --- >>> >>> Related issue which Hecate didn't clearly mention, is that Foldable >>> class default implementation has >>> >>>    class Foldable f where >>>        ... >>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>> >>> If we select option A, then I argue that for consistency the default >>> `Foldable.sum` should be >>> >>>        sum = getSum . foldMap' Sum -- strict foldMap' >>> >>> If we select option B, Foldable definition doesn't need to be changed. >>> >>> --- >>> >>> I repeat, using non-strict left fold, foldl, for sum and product is >>> not good for anything. >>> Either foldr or foldl'. >>> >>> I have no strong preference. Current state is unacceptable. >>> >>> -  Oleg >>> >>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>> >>>> On Sun, 18 Oct 2020, Hécate wrote: >>>> >>>>> In conclusion, leaving things to the optimiser that could be >>>>> trivially made fast every time seems needlessly risky. >>>> >>>> `seq` is still a hack. A strict 'sum' and 'product' would still >>>> fail on a lazy accumulator type, say a lazy pair type. If at all, >>>> sum and product should be deepseq-strict. So currently, letting the >>>> optimiser make a lazy sum strict is still the smaller hack. >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Hécate ✨ IRC: Uniaika WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Sun Oct 18 20:16:46 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 18 Oct 2020 23:16:46 +0300 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> Message-ID: <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Sorry I wasn't clear myself. Option C is "add sum'" For lists:     sum  = foldr  (+) 0     sum' = foldl' (+) 0 For Foldable     sum  = getSum #. foldMap  Sum     sum' = getSum #. foldMap' Sum - Oleg On 18.10.2020 23.11, Hécate wrote: > > Indeed, and I initially went to suggest a `foldMap'`-based > implementation to keep with the current implementation of many > Foldable functions that are based on `foldMap` rather than a raw `fold`. > > On 18/10/2020 22:04, Oleg Grenrus wrote: >> For the sake of bigger audience I didn't bother mentioning #. which >> is a coercion helper. It's essentially better (.) when the first >> argument is newtype constructor (i.e. coerce). >> >> So with Option A (strict): >> >>     sum = getSum #. foldMap' Sum >> >> Or Option B (lazy) >> >>     sum = getSum #. foldMap Sum >> >> --- >> >> There is also third option, Option C: >> >>     sum  = foldr  (+) 0 >>     sum' = foldl' (+) 0 >> >> I don't think this is worthwhile, but it is an option. >> (to rehash, I don't consider maintaining status quo to be an option >> at all). >> >> - Oleg >> On 18.10.2020 22.54, Vanessa McHale wrote: >>> >>> It's >>> >>> sum = getSum #. foldMap Sum >>> >>> in base. >>> >>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>> >>>> The problem is the current definition of sum for lists which uses >>>> foldl, i.e non-strict left fold >>>> >>>>     sum = foldl (+) 0 >>>> >>>> It's utterly broken. Either we should change it to foldl' to work >>>> on some types where addition is strict, Option A: >>>> >>>>     sum = foldl' (+) 0 >>>> >>>> or alternatively (to make people using lazy accumulator types), >>>> Option B: >>>> >>>>     sum = foldr (+) 0 >>>> >>>> The current state is no good for anyone or anything. >>>> >>>> --- >>>> >>>> Related issue which Hecate didn't clearly mention, is that Foldable >>>> class default implementation has >>>> >>>>    class Foldable f where >>>>        ... >>>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>>> >>>> If we select option A, then I argue that for consistency the >>>> default `Foldable.sum` should be >>>> >>>>        sum = getSum . foldMap' Sum -- strict foldMap' >>>> >>>> If we select option B, Foldable definition doesn't need to be changed. >>>> >>>> --- >>>> >>>> I repeat, using non-strict left fold, foldl, for sum and product is >>>> not good for anything. >>>> Either foldr or foldl'. >>>> >>>> I have no strong preference. Current state is unacceptable. >>>> >>>> -  Oleg >>>> >>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>>> >>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>>> >>>>>> In conclusion, leaving things to the optimiser that could be >>>>>> trivially made fast every time seems needlessly risky. >>>>> >>>>> `seq` is still a hack. A strict 'sum' and 'product' would still >>>>> fail on a lazy accumulator type, say a lazy pair type. If at all, >>>>> sum and product should be deepseq-strict. So currently, letting >>>>> the optimiser make a lazy sum strict is still the smaller hack. >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- > Hécate ✨ > IRC: Uniaika > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjw.hillen at gmail.com Mon Oct 19 12:56:22 2020 From: wjw.hillen at gmail.com (Wander Hillen) Date: Mon, 19 Oct 2020 14:56:22 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: Message-ID: 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. If there was a Num type with lazy structure, something like `product [] == 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. Best regards, Wander Op zo 18 okt. 2020 om 20:14 schreef Hécate : > My fellow Haskell developers, contributors and maintainers, > > I wish to present what is certainly a controversial proposal for the > `base` library: > Making the `sum` and `product` functions from the `base` library > strict. > > This is not a new question, the debate is old, but I am personally > convinced that the existence of those two lazy functions is something > that should never have happened. > One of the first goals that led to the creation of Haskell was to enable > collaboration and research in the domain of lazy (or non-strict) > programming languages and techniques. > While it led to the discovery of new methods and ways to represent > programs, we also realised that this paradigm has proven to produce > sub-optimal implementations for > these functions. > > And while maintaining backward compatibility *is* important when > designing and maintaining a programming language, we have thankfully > developed deprecation mechanisms > that can be used to signal that bad, or sub-optimal decisions of the > past can be corrected. > > To refresh our collective memory, here is the current state of things, > regarding `sum`: > > ``` > ❯ ghci +RTS -M1024m > GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help > λ❯ sum [1..10^9] > *** Exception: heap overflow > ``` > Whereas, with an alternative implementation, such as `foldl'`: > ``` > λ❯ foldl' (+) 0 [1..10^9] > 500000000500000000 > (31.35 secs, 88,000,076,288 bytes) > ``` > > I do not think a heap overflow, and the underlying space leak occasioned > by the laziness of `foldl`, are behaviours we should aim to preserve for > the sake of backward compatibility. > > And actually, I think that moving these two functions to a strict, space > leak-free implementation would benefit the lazy PL research domain by > showing a good counter-example > of why it is not necessarily suitable for every kind of computation. > I also think, and this is rooted from experience, that we must strive to > empower our users with the power of laziness. Not burden them with it. > Standing on the shoulders of giants is what made Haskell so great, but > this should not prevent us from spreading our wings to go higher. > > ——— > > Now, there have been Prelude replacements (such as Relude) and companion > libraries (like `strict`) who have been shipping such alternative > implementations for quite some time now. > > A point that can be raised is: Why should we bother? Isn't `strict` > already enough? > To this I answer: `strict` and Relude, ultimately, patches on an tire's > inner tube. We may be able to roll with them for some distance, but > their very existence is a response to an abnormal situation that we have > grown to accept. > However, any bicycle rider who has the means to change their tire should > do so. > I believe we have the means to do so. > > Another point that could be raised as well is the fact that this > implementation change would deviate from the 2010 Haskell Report[0]. > If we want to stay true to the spirit and letter of the Report, this is > actually a non-issue. Indeed, it is noted that: > > > This report defines the syntax for Haskell programs and an > informal abstract semantics for the meaning of such programs. We > leave as implementation dependent the ways in which Haskell programs are > to be manipulated, interpreted, compiled, etc. This includes such issues > as the nature of programming environments and the error messages > returned for undefined programs (i.e. programs that formally evaluate > to⊥).[1] > > As well as in chapter 9: > > > In this chapter the entire Haskell Prelude is given. It constitutes a > specification for the Prelude. Many of the definitions are written with > clarity rather than efficiency in mind, and it is not required that the > specification be implemented as shown here.[2] > > And finally, regarding the non-strict nature of Haskell, the Report > references strict evaluation to avoid "unneeded laziness."[3] > Thus it was expected that laziness would not be a silver bullet, and it > could harm performance. > > ——— > > Regarding the implementation detail, `sum` and `product` would > piggy-back on the already-present `foldMap'` function. > > > Thank you very much for reading, > I believe we can all go together towards improving the experience of > Haskell developers, starting with this. > > [0]: Haskell 2010 Language Report, > https://www.haskell.org/definition/haskell2010.pdf > [1]: Haskell 2010 Language Report, page 3 > [2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105 > [3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75 > > -- > Hécate ✨ > IRC: Uniaika > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Tue Oct 20 16:40:28 2020 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 20 Oct 2020 18:40:28 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Do we have an actual example of the use of a lazy sum in the wild? If the most common case is the strict one, making `sum` strict would be a better default. If need be we could also provide `lazySum` or something, but is there really a need? Sylvain On 18/10/2020 22:16, Oleg Grenrus wrote: > > Sorry I wasn't clear myself. Option C is "add sum'" > > For lists: > >     sum  = foldr  (+) 0 >     sum' = foldl' (+) 0 > > For Foldable > >     sum  = getSum #. foldMap  Sum >     sum' = getSum #. foldMap' Sum > > - Oleg > > On 18.10.2020 23.11, Hécate wrote: >> >> Indeed, and I initially went to suggest a `foldMap'`-based >> implementation to keep with the current implementation of many >> Foldable functions that are based on `foldMap` rather than a raw `fold`. >> >> On 18/10/2020 22:04, Oleg Grenrus wrote: >>> For the sake of bigger audience I didn't bother mentioning #. which >>> is a coercion helper. It's essentially better (.) when the first >>> argument is newtype constructor (i.e. coerce). >>> >>> So with Option A (strict): >>> >>>     sum = getSum #. foldMap' Sum >>> >>> Or Option B (lazy) >>> >>>     sum = getSum #. foldMap Sum >>> >>> --- >>> >>> There is also third option, Option C: >>> >>>     sum  = foldr  (+) 0 >>>     sum' = foldl' (+) 0 >>> >>> I don't think this is worthwhile, but it is an option. >>> (to rehash, I don't consider maintaining status quo to be an option >>> at all). >>> >>> - Oleg >>> On 18.10.2020 22.54, Vanessa McHale wrote: >>>> >>>> It's >>>> >>>> sum = getSum #. foldMap Sum >>>> >>>> in base. >>>> >>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>>> >>>>> The problem is the current definition of sum for lists which uses >>>>> foldl, i.e non-strict left fold >>>>> >>>>>     sum = foldl (+) 0 >>>>> >>>>> It's utterly broken. Either we should change it to foldl' to work >>>>> on some types where addition is strict, Option A: >>>>> >>>>>     sum = foldl' (+) 0 >>>>> >>>>> or alternatively (to make people using lazy accumulator types), >>>>> Option B: >>>>> >>>>>     sum = foldr (+) 0 >>>>> >>>>> The current state is no good for anyone or anything. >>>>> >>>>> --- >>>>> >>>>> Related issue which Hecate didn't clearly mention, is that >>>>> Foldable class default implementation has >>>>> >>>>>    class Foldable f where >>>>>        ... >>>>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>>>> >>>>> If we select option A, then I argue that for consistency the >>>>> default `Foldable.sum` should be >>>>> >>>>>        sum = getSum . foldMap' Sum -- strict foldMap' >>>>> >>>>> If we select option B, Foldable definition doesn't need to be changed. >>>>> >>>>> --- >>>>> >>>>> I repeat, using non-strict left fold, foldl, for sum and product >>>>> is not good for anything. >>>>> Either foldr or foldl'. >>>>> >>>>> I have no strong preference. Current state is unacceptable. >>>>> >>>>> -  Oleg >>>>> >>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>>>> >>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>>>> >>>>>>> In conclusion, leaving things to the optimiser that could be >>>>>>> trivially made fast every time seems needlessly risky. >>>>>> >>>>>> `seq` is still a hack. A strict 'sum' and 'product' would still >>>>>> fail on a lazy accumulator type, say a lazy pair type. If at all, >>>>>> sum and product should be deepseq-strict. So currently, letting >>>>>> the optimiser make a lazy sum strict is still the smaller hack. >>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> -- >> Hécate ✨ >> IRC: Uniaika >> WWW:https://glitchbra.in >> RUN: BSD >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Wed Oct 21 19:36:43 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Wed, 21 Oct 2020 19:36:43 +0000 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: I can't think of an example where a raw lazy `sum` would be preferable to a strict version. If summing over infinite data structures, it will always be prefixed by a `take` or a `drop` prior to summing to make sure we work with finite chunks. In which case, a strict sum is still better. Maybe someone has a more complex, contrived example showing the usefulness of lazy sums. The fact that no one seems to be able to name one in this or other discussions, or come up with a contrived example, is a good indicator to me that at least the default should be strict in this case. We should offer a lazy variant as a second option, not the first. I'm in favor of Oleg's `foldMap` implementation. It's really clean. Also thank you Hécate! Cheers, Emily On Tue, Oct 20, 2020 at 12:40 PM, Sylvain Henry < sylvain at haskus.fr > wrote: > > > > Do we have an actual example of the use of a lazy sum in the wild? > > > > If the most common case is the strict one, making `sum` strict would be a > better default. If need be we could also provide `lazySum` or something, > but is there really a need? > > > > Sylvain > > > > > > > > On 18/10/2020 22:16, Oleg Grenrus wrote: > > >> >> >> Sorry I wasn't clear myself. Option C is "add sum'" >> >> For lists: >> >> sum  = foldr  (+) 0 >> sum' = foldl' (+) 0 >> >> For Foldable >> >> sum  = getSum #. foldMap  Sum >> sum' = getSum #. foldMap' Sum >> >> >> >> - Oleg >> >> >> On 18.10.2020 23.11, Hécate wrote: >> >> >>> >>> >>> Indeed, and I initially went to suggest a `foldMap'`-based implementation >>> to keep with the current implementation of many Foldable functions that >>> are based on `foldMap` rather than a raw `fold`. >>> >>> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>> >>> >>>> For the sake of bigger audience I didn't bother mentioning #. which is a >>>> coercion helper. It's essentially better (.) when the first argument is >>>> newtype constructor (i.e. coerce). >>>> >>>> So with Option A (strict): >>>> >>>> sum = getSum #. foldMap' Sum >>>> >>>> Or Option B (lazy) >>>> >>>> sum = getSum #. foldMap Sum >>>> >>>> --- >>>> >>>> There is also third option, Option C: >>>> >>>> sum  = foldr  (+) 0 >>>> sum' = foldl' (+) 0 >>>> >>>> I don't think this is worthwhile, but it is an option. >>>> (to rehash, I don't consider maintaining status quo to be an option at >>>> all). >>>> >>>> - Oleg >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >>>> >>>> >>>>> >>>>> >>>>> It's >>>>> >>>>> >>>>> >>>>> >>>>> sum = getSum #. foldMap Sum >>>>> >>>>> in base. >>>>> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> The problem is the current definition of sum for lists which uses foldl, >>>>>> i.e non-strict left fold >>>>>> >>>>>> >>>>>> >>>>>> sum = foldl (+) 0 >>>>>> >>>>>> It's utterly broken. Either we should change it to foldl' to work on some >>>>>> types where addition is strict, Option A: >>>>>> >>>>>> sum = foldl' (+) 0 >>>>>> >>>>>> or alternatively (to make people using lazy accumulator types), Option B: >>>>>> >>>>>> sum = foldr (+) 0 >>>>>> >>>>>> The current state is no good for anyone or anything. >>>>>> >>>>>> --- >>>>>> >>>>>> Related issue which Hecate didn't clearly mention, is that Foldable class >>>>>> default implementation has >>>>>> >>>>>> class Foldable f where >>>>>> ... >>>>>> sum = getSum . foldMap Sum -- this is "good" lazy definition >>>>>> >>>>>> If we select option A, then I argue that for consistency the default >>>>>> `Foldable.sum` should be >>>>>> >>>>>> sum = getSum . foldMap' Sum -- strict foldMap' >>>>>> >>>>>> If we select option B, Foldable definition doesn't need to be changed. >>>>>> >>>>>> --- >>>>>> >>>>>> I repeat, using non-strict left fold, foldl, for sum and product is not >>>>>> good for anything. >>>>>> Either foldr or foldl'. >>>>>> >>>>>> I have no strong preference. Current state is unacceptable. >>>>>> >>>>>> -  Oleg >>>>>> >>>>>> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>>>>> >>>>>>> >>>>>>>> In conclusion, leaving things to the optimiser that could be trivially >>>>>>>> made fast every time seems needlessly risky. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' would still fail on a >>>>>>> lazy accumulator type, say a lazy pair type. If at all, sum and product >>>>>>> should be deepseq-strict. So currently, letting the optimiser make a lazy >>>>>>> sum strict is still the smaller hack. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Libraries mailing list >>>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>> >>> >>> -- >>> Hécate ✨ >>> IRC: Uniaika >>> WWW: https:/ / glitchbra. in ( https://glitchbra.in ) >>> RUN: BSD >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@ haskell. org ( Libraries at haskell.org ) >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >> > > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Wed Oct 21 20:10:52 2020 From: chessai1996 at gmail.com (chessai) Date: Wed, 21 Oct 2020 15:10:52 -0500 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: I'm pretty strongly in favour of a sum implemented using foldMap'. The status quo is atrocious (cf. Oleg's emails), and the utility of a lazy right fold is low in practise. On Wed, Oct 21, 2020, 14:38 Emily Pillmore wrote: > I can't think of an example where a raw lazy `sum` would be preferable to > a strict version. If summing over infinite data structures, it will always > be prefixed by a `take` or a `drop` prior to summing to make sure we work > with finite chunks. In which case, a strict sum is still better. Maybe > someone has a more complex, contrived example showing the usefulness of > lazy sums. > > The fact that no one seems to be able to name one in this or other > discussions, or come up with a contrived example, is a good indicator to me > that at least the default should be strict in this case. We should offer a > lazy variant as a second option, not the first. > > I'm in favor of Oleg's `foldMap` implementation. It's really clean. Also > thank you Hécate! > > Cheers, > Emily > > > On Tue, Oct 20, 2020 at 12:40 PM, Sylvain Henry wrote: > >> Do we have an actual example of the use of a lazy sum in the wild? >> >> If the most common case is the strict one, making `sum` strict would be a >> better default. If need be we could also provide `lazySum` or something, >> but is there really a need? >> >> Sylvain >> >> >> On 18/10/2020 22:16, Oleg Grenrus wrote: >> >> Sorry I wasn't clear myself. Option C is "add sum'" >> >> For lists: >> >> sum = foldr (+) 0 >> sum' = foldl' (+) 0 >> >> For Foldable >> >> sum = getSum #. foldMap Sum >> sum' = getSum #. foldMap' Sum >> >> - Oleg >> On 18.10.2020 23.11, Hécate wrote: >> >> Indeed, and I initially went to suggest a `foldMap'`-based implementation >> to keep with the current implementation of many Foldable functions that are >> based on `foldMap` rather than a raw `fold`. >> On 18/10/2020 22:04, Oleg Grenrus wrote: >> >> For the sake of bigger audience I didn't bother mentioning #. which is a >> coercion helper. It's essentially better (.) when the first argument is >> newtype constructor (i.e. coerce). >> >> So with Option A (strict): >> >> sum = getSum #. foldMap' Sum >> >> Or Option B (lazy) >> >> sum = getSum #. foldMap Sum >> >> --- >> >> There is also third option, Option C: >> >> sum = foldr (+) 0 >> sum' = foldl' (+) 0 >> >> I don't think this is worthwhile, but it is an option. >> (to rehash, I don't consider maintaining status quo to be an option at >> all). >> >> - Oleg >> On 18.10.2020 22.54, Vanessa McHale wrote: >> >> It's >> >> sum = getSum #. foldMap Sum >> >> in base. >> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >> >> The problem is the current definition of sum for lists which uses foldl, >> i.e non-strict left fold >> >> sum = foldl (+) 0 >> >> It's utterly broken. Either we should change it to foldl' to work on some >> types where addition is strict, Option A: >> >> sum = foldl' (+) 0 >> >> or alternatively (to make people using lazy accumulator types), Option B: >> >> sum = foldr (+) 0 >> >> The current state is no good for anyone or anything. >> >> --- >> >> Related issue which Hecate didn't clearly mention, is that Foldable class >> default implementation has >> >> class Foldable f where >> ... >> sum = getSum . foldMap Sum -- this is "good" lazy definition >> >> If we select option A, then I argue that for consistency the default >> `Foldable.sum` should be >> >> sum = getSum . foldMap' Sum -- strict foldMap' >> >> If we select option B, Foldable definition doesn't need to be changed. >> >> --- >> >> I repeat, using non-strict left fold, foldl, for sum and product is not >> good for anything. >> Either foldr or foldl'. >> >> I have no strong preference. Current state is unacceptable. >> >> - Oleg >> On 18.10.2020 22.24, Henning Thielemann wrote: >> >> >> On Sun, 18 Oct 2020, Hécate wrote: >> >> In conclusion, leaving things to the optimiser that could be trivially >> made fast every time seems needlessly risky. >> >> >> `seq` is still a hack. A strict 'sum' and 'product' would still fail on a >> lazy accumulator type, say a lazy pair type. If at all, sum and product >> should be deepseq-strict. So currently, letting the optimiser make a lazy >> sum strict is still the smaller hack. >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -- >> Hécate [image: ✨] >> IRC: Uniaika >> WWW: https://glitchbra.in >> RUN: BSD >> >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Oct 21 21:49:39 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 21 Oct 2020 17:49:39 -0400 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Even worse, it’s using foldl on lists, when, to the best of my knowledge, only foldr and foldl’ ever make sense for finite Haskell lists. Not sure about infinite lists ;) On Wed, Oct 21, 2020 at 4:11 PM chessai wrote: > I'm pretty strongly in favour of a sum implemented using foldMap'. The > status quo is atrocious (cf. Oleg's emails), and the utility of a lazy > right fold is low in practise. > > On Wed, Oct 21, 2020, 14:38 Emily Pillmore wrote: > >> I can't think of an example where a raw lazy `sum` would be preferable to >> a strict version. If summing over infinite data structures, it will always >> be prefixed by a `take` or a `drop` prior to summing to make sure we work >> with finite chunks. In which case, a strict sum is still better. Maybe >> someone has a more complex, contrived example showing the usefulness of >> lazy sums. >> >> The fact that no one seems to be able to name one in this or other >> discussions, or come up with a contrived example, is a good indicator to me >> that at least the default should be strict in this case. We should offer a >> lazy variant as a second option, not the first. >> >> I'm in favor of Oleg's `foldMap` implementation. It's really clean. Also >> thank you Hécate! >> >> Cheers, >> Emily >> >> >> On Tue, Oct 20, 2020 at 12:40 PM, Sylvain Henry >> wrote: >> >>> Do we have an actual example of the use of a lazy sum in the wild? >>> >>> If the most common case is the strict one, making `sum` strict would be >>> a better default. If need be we could also provide `lazySum` or something, >>> but is there really a need? >>> >>> Sylvain >>> >>> >>> On 18/10/2020 22:16, Oleg Grenrus wrote: >>> >>> Sorry I wasn't clear myself. Option C is "add sum'" >>> >>> For lists: >>> >>> sum = foldr (+) 0 >>> sum' = foldl' (+) 0 >>> >>> For Foldable >>> >>> sum = getSum #. foldMap Sum >>> sum' = getSum #. foldMap' Sum >>> >>> - Oleg >>> On 18.10.2020 23.11, Hécate wrote: >>> >>> Indeed, and I initially went to suggest a `foldMap'`-based >>> implementation to keep with the current implementation of many Foldable >>> functions that are based on `foldMap` rather than a raw `fold`. >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>> >>> For the sake of bigger audience I didn't bother mentioning #. which is a >>> coercion helper. It's essentially better (.) when the first argument is >>> newtype constructor (i.e. coerce). >>> >>> So with Option A (strict): >>> >>> sum = getSum #. foldMap' Sum >>> >>> Or Option B (lazy) >>> >>> sum = getSum #. foldMap Sum >>> >>> --- >>> >>> There is also third option, Option C: >>> >>> sum = foldr (+) 0 >>> sum' = foldl' (+) 0 >>> >>> I don't think this is worthwhile, but it is an option. >>> (to rehash, I don't consider maintaining status quo to be an option at >>> all). >>> >>> - Oleg >>> On 18.10.2020 22.54, Vanessa McHale wrote: >>> >>> It's >>> >>> sum = getSum #. foldMap Sum >>> >>> in base. >>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>> >>> The problem is the current definition of sum for lists which uses foldl, >>> i.e non-strict left fold >>> >>> sum = foldl (+) 0 >>> >>> It's utterly broken. Either we should change it to foldl' to work on >>> some types where addition is strict, Option A: >>> >>> sum = foldl' (+) 0 >>> >>> or alternatively (to make people using lazy accumulator types), Option B: >>> >>> sum = foldr (+) 0 >>> >>> The current state is no good for anyone or anything. >>> >>> --- >>> >>> Related issue which Hecate didn't clearly mention, is that Foldable >>> class default implementation has >>> >>> class Foldable f where >>> ... >>> sum = getSum . foldMap Sum -- this is "good" lazy definition >>> >>> If we select option A, then I argue that for consistency the default >>> `Foldable.sum` should be >>> >>> sum = getSum . foldMap' Sum -- strict foldMap' >>> >>> If we select option B, Foldable definition doesn't need to be changed. >>> >>> --- >>> >>> I repeat, using non-strict left fold, foldl, for sum and product is not >>> good for anything. >>> Either foldr or foldl'. >>> >>> I have no strong preference. Current state is unacceptable. >>> >>> - Oleg >>> On 18.10.2020 22.24, Henning Thielemann wrote: >>> >>> >>> On Sun, 18 Oct 2020, Hécate wrote: >>> >>> In conclusion, leaving things to the optimiser that could be trivially >>> made fast every time seems needlessly risky. >>> >>> >>> `seq` is still a hack. A strict 'sum' and 'product' would still fail on >>> a lazy accumulator type, say a lazy pair type. If at all, sum and product >>> should be deepseq-strict. So currently, letting the optimiser make a lazy >>> sum strict is still the smaller hack. >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> -- >>> Hécate [image: ✨] >>> IRC: Uniaika >>> WWW: https://glitchbra.in >>> RUN: BSD >>> >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.fairbairn at cl.cam.ac.uk Thu Oct 22 09:35:39 2020 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu, 22 Oct 2020 10:35:39 +0100 Subject: [Proposal] Strict `sum` and `product` References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Sylvain Henry writes: > Do we have an actual example of the use of a lazy sum in the > wild? That’s not a very good argument, though I’ve seen it used quite a lot. The problem is that just because no-one can currently think of a “real” example it doesn’t mean that there are no cases where laziness is required. For a forced example, consider a wrapping of Double with a test for infinity on the left argument … a + b | isInfinite a = a … which doesn’t evaluate it’s second argument if the first is infinite. > If the most common case is the strict one, making `sum` > strict would be a better default. Haskell should remain a lazy language, so the defaults should be lazy unless they can be proved strict anyway. > If need be we could also provide `lazySum` or something, but > is there really a need? Who can truly say? I’d support sum' as the strict version as that is consistent with other usages. — Jón > > Sylvain > > > On 18/10/2020 22:16, Oleg Grenrus wrote: >> >> Sorry I wasn't clear myself. Option C is "add sum'" >> >> For lists: >> >>     sum  = foldr  (+) 0 >>     sum' = foldl' (+) 0 >> >> For Foldable >> >>     sum  = getSum #. foldMap  Sum >>     sum' = getSum #. foldMap' Sum >> >> - Oleg >> >> On 18.10.2020 23.11, Hécate wrote: >>> >>> Indeed, and I initially went to suggest a >>> foldMap'`-based implementation to keep with the current >>> implementation of many Foldable functions that are based >>> on `foldMap` rather than a raw `fold`. >>> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>>> For the sake of bigger audience I didn't bother >>>> mentioning #. which is a coercion helper. It's >>>> essentially better (.) when the first argument is >>>> newtype constructor (i.e. coerce). >>>> >>>> So with Option A (strict): >>>> >>>>     sum = getSum #. foldMap' Sum >>>> >>>> Or Option B (lazy) >>>> >>>>     sum = getSum #. foldMap Sum >>>> >>>> --- >>>> >>>> There is also third option, Option C: >>>> >>>>     sum  = foldr  (+) 0 >>>>     sum' = foldl' (+) 0 >>>> >>>> I don't think this is worthwhile, but it is an option. >>>> (to rehash, I don't consider maintaining status quo to >>>> be an option at all). >>>> >>>> - Oleg >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >>>>> >>>>> It's >>>>> >>>>> sum = getSum #. foldMap Sum >>>>> >>>>> in base. >>>>> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>>>> >>>>>> The problem is the current definition of sum for lists >>>>>> which uses foldl, i.e non-strict left fold >>>>>> >>>>>>     sum = foldl (+) 0 >>>>>> >>>>>> It's utterly broken. Either we should change it to >>>>>> foldl' to work on some types where addition is strict, >>>>>> Option A: >>>>>> >>>>>>     sum = foldl' (+) 0 >>>>>> >>>>>> or alternatively (to make people using lazy >>>>>> accumulator types), Option B: >>>>>> >>>>>>     sum = foldr (+) 0 >>>>>> >>>>>> The current state is no good for anyone or anything. >>>>>> >>>>>> --- >>>>>> >>>>>> Related issue which Hecate didn't clearly mention, is >>>>>> that Foldable class default implementation has >>>>>> >>>>>>    class Foldable f where >>>>>>        ... >>>>>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>>>>> >>>>>> If we select option A, then I argue that for >>>>>> consistency the default `Foldable.sum` should be >>>>>> >>>>>>        sum = getSum . foldMap' Sum -- strict foldMap' >>>>>> >>>>>> If we select option B, Foldable definition doesn't need to be changed. >>>>>> >>>>>> --- >>>>>> >>>>>> I repeat, using non-strict left fold, foldl, for sum >>>>>> and product is not good for anything. >>>>>> Either foldr or foldl'. >>>>>> >>>>>> I have no strong preference. Current state is unacceptable. >>>>>> >>>>>> -  Oleg >>>>>> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>>>>> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>>>>> >>>>>>>> In conclusion, leaving things to the optimiser that >>>>>>>> could be trivially made fast every time seems >>>>>>>> needlessly risky. >>>>>>> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' >>>>>>> would still fail on a lazy accumulator type, say a >>>>>>> lazy pair type. If at all, sum and product should be >>>>>>> deepseq-strict. So currently, letting the optimiser >>>>>>> make a lazy sum strict is still the smaller hack. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Libraries mailing list >>>>>>> Libraries at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> >>>>>> _______________________________________________ >>>>>> Libraries mailing list >>>>>> Libraries at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> -- >>> Hécate ✨ >>> IRC: Uniaika >>> WWW:https://glitchbra.in >>> RUN: BSD >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05) From duke.j.david at gmail.com Thu Oct 22 10:18:01 2020 From: duke.j.david at gmail.com (David Duke) Date: Thu, 22 Oct 2020 11:18:01 +0100 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Concur with Jon's point. I'm uncomfortable with making foldMap/sum strict. Haskell was intended to explore a region of the programming design space that had not been well covered. and it remains if not unique then at least exemplary in that respect. When I write in Haskell I do so with the knowledge that I am working with lazy evaluation with the benefits and risk that comes with that. If I'm desperate to have finer operational control, I either swallow that pill and adapt my use of Haskell accordingly, or pick up a different tool from the programming language toolbox. Now the OP pointed to an issue with one specific use of sum. However, that seems like weak grounds to make library changes: 1. we dont knowing the context. the best way to avoid the cost of computation is not to compute it; what alternatives are there i this s[ecific problem. 2. if one was to make foldMap/sum strict why not also other functions, e.g. scanAccum, where does one stop on the grounds of possibly saving costs in so as yet unknown application 3. Instead of thinking/programming in a pure lazy language, you are then in the position of thinking lazily apart from some set of to be determined exceptional cases. the simplicity and uniformity of the model is gone. 4. As per item 3 but from a pedagogical point of view. I taught UG FP for years. Complicating the model is not going to help students, to say nothing of the caveats that would have to be added to existing teaching materials. So whilst the post was clearly intended to trigger discussion, in terms on conveying sentiment a strict foldMap would be a big '-' for me personally. Whilst there are performance challenges in working with Haskell. The primary role of the programming notation is allowing one to think about the problem and obtain a clear, correct solution. Performance tuning comes later if at all, and her are known techniques for doing so with Haskell/ghc. 5. OTOH I see little harm in adding a library that provides a strict foldMap for those who want to use it after deliberate thought. YMMMocV David On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn wrote: > Sylvain Henry writes: > > > Do we have an actual example of the use of a lazy sum in the > > wild? > > That’s not a very good argument, though I’ve seen it used quite > a lot. The problem is that just because no-one can currently > think of a “real” example it doesn’t mean that there are no > cases where laziness is required. > > For a forced example, consider a wrapping of Double with a test > for infinity on the left argument > > … > a + b | isInfinite a = a > … > > which doesn’t evaluate it’s second argument if the first is > infinite. > > > If the most common case is the strict one, making `sum` > > strict would be a better default. > > Haskell should remain a lazy language, so the defaults should be > lazy unless they can be proved strict anyway. > > > If need be we could also provide `lazySum` or something, but > > is there really a need? > > Who can truly say? I’d support sum' as the strict version as > that is consistent with other usages. > > — Jón > > > > > Sylvain > > > > > > On 18/10/2020 22:16, Oleg Grenrus wrote: > >> > >> Sorry I wasn't clear myself. Option C is "add sum'" > >> > >> For lists: > >> > >> sum = foldr (+) 0 > >> sum' = foldl' (+) 0 > >> > >> For Foldable > >> > >> sum = getSum #. foldMap Sum > >> sum' = getSum #. foldMap' Sum > >> > >> - Oleg > >> > >> On 18.10.2020 23.11, Hécate wrote: > >>> > >>> Indeed, and I initially went to suggest a > >>> foldMap'`-based implementation to keep with the current > >>> implementation of many Foldable functions that are based > >>> on `foldMap` rather than a raw `fold`. > >>> > >>> On 18/10/2020 22:04, Oleg Grenrus wrote: > >>>> For the sake of bigger audience I didn't bother > >>>> mentioning #. which is a coercion helper. It's > >>>> essentially better (.) when the first argument is > >>>> newtype constructor (i.e. coerce). > >>>> > >>>> So with Option A (strict): > >>>> > >>>> sum = getSum #. foldMap' Sum > >>>> > >>>> Or Option B (lazy) > >>>> > >>>> sum = getSum #. foldMap Sum > >>>> > >>>> --- > >>>> > >>>> There is also third option, Option C: > >>>> > >>>> sum = foldr (+) 0 > >>>> sum' = foldl' (+) 0 > >>>> > >>>> I don't think this is worthwhile, but it is an option. > >>>> (to rehash, I don't consider maintaining status quo to > >>>> be an option at all). > >>>> > >>>> - Oleg > >>>> On 18.10.2020 22.54, Vanessa McHale wrote: > >>>>> > >>>>> It's > >>>>> > >>>>> sum = getSum #. foldMap Sum > >>>>> > >>>>> in base. > >>>>> > >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: > >>>>>> > >>>>>> The problem is the current definition of sum for lists > >>>>>> which uses foldl, i.e non-strict left fold > >>>>>> > >>>>>> sum = foldl (+) 0 > >>>>>> > >>>>>> It's utterly broken. Either we should change it to > >>>>>> foldl' to work on some types where addition is strict, > >>>>>> Option A: > >>>>>> > >>>>>> sum = foldl' (+) 0 > >>>>>> > >>>>>> or alternatively (to make people using lazy > >>>>>> accumulator types), Option B: > >>>>>> > >>>>>> sum = foldr (+) 0 > >>>>>> > >>>>>> The current state is no good for anyone or anything. > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Related issue which Hecate didn't clearly mention, is > >>>>>> that Foldable class default implementation has > >>>>>> > >>>>>> class Foldable f where > >>>>>> ... > >>>>>> sum = getSum . foldMap Sum -- this is "good" lazy definition > >>>>>> > >>>>>> If we select option A, then I argue that for > >>>>>> consistency the default `Foldable.sum` should be > >>>>>> > >>>>>> sum = getSum . foldMap' Sum -- strict foldMap' > >>>>>> > >>>>>> If we select option B, Foldable definition doesn't need to be > changed. > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> I repeat, using non-strict left fold, foldl, for sum > >>>>>> and product is not good for anything. > >>>>>> Either foldr or foldl'. > >>>>>> > >>>>>> I have no strong preference. Current state is unacceptable. > >>>>>> > >>>>>> - Oleg > >>>>>> > >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: > >>>>>>> > >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: > >>>>>>> > >>>>>>>> In conclusion, leaving things to the optimiser that > >>>>>>>> could be trivially made fast every time seems > >>>>>>>> needlessly risky. > >>>>>>> > >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' > >>>>>>> would still fail on a lazy accumulator type, say a > >>>>>>> lazy pair type. If at all, sum and product should be > >>>>>>> deepseq-strict. So currently, letting the optimiser > >>>>>>> make a lazy sum strict is still the smaller hack. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Libraries mailing list > >>>>>>> Libraries at haskell.org > >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Libraries mailing list > >>>>>> Libraries at haskell.org > >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>>> > >>>>> _______________________________________________ > >>>>> Libraries mailing list > >>>>> Libraries at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>> > >>>> _______________________________________________ > >>>> Libraries mailing list > >>>> Libraries at haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> -- > >>> Hécate ✨ > >>> IRC: Uniaika > >>> WWW:https://glitchbra.in > >>> RUN: BSD > >>> > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- > Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk > http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjw.hillen at gmail.com Thu Oct 22 10:38:32 2020 From: wjw.hillen at gmail.com (Wander Hillen) Date: Thu, 22 Oct 2020 12:38:32 +0200 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: I don't think this example shows that a lazy fold would be better. Even if the combining argument of the fold is not strict in the second argument, evaluating something like "sum [Infinity, 1, 2, 3]" with the infinity-shorting double will still touch every element in the list. As I understand it, to actually benefit from laziness in these functions they'd need both a lazy combining function AND a lazy accumulator type (which Double is not). For a practical example of where a shortcut might be possible, consider a case like "if (product [1,2,3,0,4,5]) < 20 then f x else g y". Evaluation of the list could theoretically stop after it encounters the zero [0] since after that any further elements in the list will no longer change the value of the outcome. I don't think that this actually occurs however and doubt the various fold functions could be rewritten in such a way as to handle this in the general case as long as the accumulator type is strict. As was mentioned earlier, all of the Num types in base are strict and both `sum` and `product` have a Num constraint. If lazy shortcutting is important, a small custom function that recurses over the list and tests for problem-specific edge cases will still be possible. I disagree btw with the statement that we should not change this even though nobody can think of a compelling reason not to because we might think of such a reason later. That standpoint in its extreme can only lead to paralysis, since it is not always possible to prove no reasons will be thought of later. Davids mail came in as I was writing this, I do agree with many of his points regarding laziness but would like to point out that as Haskell was/is intended to explore laziness in programming, we should eventually be able to get the benefits from these explorations as well. Negative results can be as valuable as positive results after all, so if "we-the-library-writers" discover a place where laziness is not ideal it should be possible (encouraged even) to apply this learning and change our language for the better. In this specific case (sum and product only), the use of strict accumulator types results in strict behavior already and therefore we lose nothing by changing from lazy to strict foldl. The proposal is NOT about removing lazy folds in general, just these two particular cases where they do not bring any benefits but do bring space leaks. Wander [0]: This is an optimization we see in the implementation of Integer multiplication . It does not work for `product` though, only for `(*)`. Op do 22 okt. 2020 om 11:36 schreef Jon Fairbairn < jon.fairbairn at cl.cam.ac.uk>: > Sylvain Henry writes: > > > Do we have an actual example of the use of a lazy sum in the > > wild? > > That’s not a very good argument, though I’ve seen it used quite > a lot. The problem is that just because no-one can currently > think of a “real” example it doesn’t mean that there are no > cases where laziness is required. > > For a forced example, consider a wrapping of Double with a test > for infinity on the left argument > > … > a + b | isInfinite a = a > … > > which doesn’t evaluate it’s second argument if the first is > infinite. > > > If the most common case is the strict one, making `sum` > > strict would be a better default. > > Haskell should remain a lazy language, so the defaults should be > lazy unless they can be proved strict anyway. > > > If need be we could also provide `lazySum` or something, but > > is there really a need? > > Who can truly say? I’d support sum' as the strict version as > that is consistent with other usages. > > — Jón > > > > > Sylvain > > > > > > On 18/10/2020 22:16, Oleg Grenrus wrote: > >> > >> Sorry I wasn't clear myself. Option C is "add sum'" > >> > >> For lists: > >> > >> sum = foldr (+) 0 > >> sum' = foldl' (+) 0 > >> > >> For Foldable > >> > >> sum = getSum #. foldMap Sum > >> sum' = getSum #. foldMap' Sum > >> > >> - Oleg > >> > >> On 18.10.2020 23.11, Hécate wrote: > >>> > >>> Indeed, and I initially went to suggest a > >>> foldMap'`-based implementation to keep with the current > >>> implementation of many Foldable functions that are based > >>> on `foldMap` rather than a raw `fold`. > >>> > >>> On 18/10/2020 22:04, Oleg Grenrus wrote: > >>>> For the sake of bigger audience I didn't bother > >>>> mentioning #. which is a coercion helper. It's > >>>> essentially better (.) when the first argument is > >>>> newtype constructor (i.e. coerce). > >>>> > >>>> So with Option A (strict): > >>>> > >>>> sum = getSum #. foldMap' Sum > >>>> > >>>> Or Option B (lazy) > >>>> > >>>> sum = getSum #. foldMap Sum > >>>> > >>>> --- > >>>> > >>>> There is also third option, Option C: > >>>> > >>>> sum = foldr (+) 0 > >>>> sum' = foldl' (+) 0 > >>>> > >>>> I don't think this is worthwhile, but it is an option. > >>>> (to rehash, I don't consider maintaining status quo to > >>>> be an option at all). > >>>> > >>>> - Oleg > >>>> On 18.10.2020 22.54, Vanessa McHale wrote: > >>>>> > >>>>> It's > >>>>> > >>>>> sum = getSum #. foldMap Sum > >>>>> > >>>>> in base. > >>>>> > >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: > >>>>>> > >>>>>> The problem is the current definition of sum for lists > >>>>>> which uses foldl, i.e non-strict left fold > >>>>>> > >>>>>> sum = foldl (+) 0 > >>>>>> > >>>>>> It's utterly broken. Either we should change it to > >>>>>> foldl' to work on some types where addition is strict, > >>>>>> Option A: > >>>>>> > >>>>>> sum = foldl' (+) 0 > >>>>>> > >>>>>> or alternatively (to make people using lazy > >>>>>> accumulator types), Option B: > >>>>>> > >>>>>> sum = foldr (+) 0 > >>>>>> > >>>>>> The current state is no good for anyone or anything. > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Related issue which Hecate didn't clearly mention, is > >>>>>> that Foldable class default implementation has > >>>>>> > >>>>>> class Foldable f where > >>>>>> ... > >>>>>> sum = getSum . foldMap Sum -- this is "good" lazy definition > >>>>>> > >>>>>> If we select option A, then I argue that for > >>>>>> consistency the default `Foldable.sum` should be > >>>>>> > >>>>>> sum = getSum . foldMap' Sum -- strict foldMap' > >>>>>> > >>>>>> If we select option B, Foldable definition doesn't need to be > changed. > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> I repeat, using non-strict left fold, foldl, for sum > >>>>>> and product is not good for anything. > >>>>>> Either foldr or foldl'. > >>>>>> > >>>>>> I have no strong preference. Current state is unacceptable. > >>>>>> > >>>>>> - Oleg > >>>>>> > >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: > >>>>>>> > >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: > >>>>>>> > >>>>>>>> In conclusion, leaving things to the optimiser that > >>>>>>>> could be trivially made fast every time seems > >>>>>>>> needlessly risky. > >>>>>>> > >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' > >>>>>>> would still fail on a lazy accumulator type, say a > >>>>>>> lazy pair type. If at all, sum and product should be > >>>>>>> deepseq-strict. So currently, letting the optimiser > >>>>>>> make a lazy sum strict is still the smaller hack. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Libraries mailing list > >>>>>>> Libraries at haskell.org > >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Libraries mailing list > >>>>>> Libraries at haskell.org > >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>>> > >>>>> _______________________________________________ > >>>>> Libraries mailing list > >>>>> Libraries at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>> > >>>> _______________________________________________ > >>>> Libraries mailing list > >>>> Libraries at haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> -- > >>> Hécate ✨ > >>> IRC: Uniaika > >>> WWW:https://glitchbra.in > >>> RUN: BSD > >>> > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- > Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk > http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Thu Oct 22 11:05:02 2020 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Thu, 22 Oct 2020 20:05:02 +0900 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: > > For a forced example, consider a wrapping of Double with a test > for infinity on the left argument > > … > a + b | isInfinite a = a > … > This makes sense only if sum is foldr (+) 0, while the implementation of sum for lists is foldl (+) 0. But hey, we are comparing a hypothetical type with hundreds of real world uses. Haskell should remain a lazy language > I'm not sure if I agree. We've been bitten by laziness too much, hence the introduction of BangPatterns, StrictData, deepseq, etc. IMO Haskell ecosystem should be more strict. I'm uncomfortable with making foldMap/sum strict. > No one is suggesting to change foldMap; what OP wants to change is sum and product, and foldMap _happens to be_ the current default implementation. > we dont knowing the context. the best way to avoid the cost of > computation is not to compute it; what alternatives are there > i this s[ecific problem. > The context is pretty clear; the status quo (sum = foldl (+) 0) is flat-out wrong. I'd say more than 80% of the uses of sum is supposed to look at all the elements. And even if (+) is short-circuiting in the way Jon suggested, lazy foldl does not take any advantage of it. if one was to make foldMap/sum strict why not also other functions, e.g. > scanAccum, where does one stop on the grounds of possibly saving costs in > so as yet > unknown application > I'm not sure which function you are talking about (there's no function called scanAccum in base nor containers). If you mean scanl, lazy accumulator still makes sense because the resulting list can be consumed incrementally. foldl is not. Instead of thinking/programming in a pure lazy language, you are then in > the position of thinking lazily apart from some set of > to be determined exceptional cases. the simplicity and uniformity of the > model is gone. > Again, there's little to be gained from lazy foldl. It's avoided in general and I'd say it's not "uniform" to use the function. 4. As per item 3 but from a pedagogical point of view. I taught UG FP for > years. Complicating the model is not going to help students, > to say nothing of the caveats that would have to be added to > existing teaching materials. > Also from a pedagogical point of view, a number of beginners fall into a trap of lazy foldl. Caveats should be added to the current one if at all, but this danger zone can be removed with one byte change. I'm seriously worried that the use of foldl in the standard library might make beginners think that it's fine to use foldl. As far as I remember, the same change has been suggested a while ago but didn't make it. I hope we don't get discouraged this time and go ahead with the change. 2020年10月22日(木) 19:19 David Duke : > Concur with Jon's point. > I'm uncomfortable with making foldMap/sum strict. > Haskell was intended to explore a region of the programming design space > that had not been well covered. and it remains > if not unique then at least exemplary in that respect. When I write > in Haskell I do so with the knowledge that I am working with > lazy evaluation with the benefits and risk that comes with that. If I'm > desperate to have finer operational control, I either > swallow that pill and adapt my use of Haskell accordingly, or pick up a > different tool from the programming language toolbox. > > Now the OP pointed to an issue with one specific use of sum. However, that > seems like weak grounds to make library changes: > 1. we dont knowing the context. the best way to avoid the cost of > computation is not to compute it; what alternatives are there > i this s[ecific problem. > 2. if one was to make foldMap/sum strict why not also other functions, > e.g. scanAccum, where does one stop on the grounds of possibly saving costs > in so as yet > unknown application > 3. Instead of thinking/programming in a pure lazy language, you are then > in the position of thinking lazily apart from some set of > to be determined exceptional cases. the simplicity and uniformity of the > model is gone. > 4. As per item 3 but from a pedagogical point of view. I taught UG FP for > years. Complicating the model is not going to help students, > to say nothing of the caveats that would have to be added to > existing teaching materials. > So whilst the post was clearly intended to trigger discussion, in terms > on conveying sentiment a strict foldMap would be a big '-' > for me personally. Whilst there are performance challenges in working > with Haskell. The primary role of the programming notation > is allowing one to think about the problem and obtain a clear, correct > solution. Performance tuning comes later if at all, and > her are known techniques for doing so with Haskell/ghc. > 5. OTOH I see little harm in adding a library that provides a strict > foldMap for those > who want to use it after deliberate thought. > > YMMMocV > David > > > > > > > > On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn > wrote: > >> Sylvain Henry writes: >> >> > Do we have an actual example of the use of a lazy sum in the >> > wild? >> >> That’s not a very good argument, though I’ve seen it used quite >> a lot. The problem is that just because no-one can currently >> think of a “real” example it doesn’t mean that there are no >> cases where laziness is required. >> >> For a forced example, consider a wrapping of Double with a test >> for infinity on the left argument >> >> … >> a + b | isInfinite a = a >> … >> >> which doesn’t evaluate it’s second argument if the first is >> infinite. >> >> > If the most common case is the strict one, making `sum` >> > strict would be a better default. >> >> Haskell should remain a lazy language, so the defaults should be >> lazy unless they can be proved strict anyway. >> >> > If need be we could also provide `lazySum` or something, but >> > is there really a need? >> >> Who can truly say? I’d support sum' as the strict version as >> that is consistent with other usages. >> >> — Jón >> >> > >> > Sylvain >> > >> > >> > On 18/10/2020 22:16, Oleg Grenrus wrote: >> >> >> >> Sorry I wasn't clear myself. Option C is "add sum'" >> >> >> >> For lists: >> >> >> >> sum = foldr (+) 0 >> >> sum' = foldl' (+) 0 >> >> >> >> For Foldable >> >> >> >> sum = getSum #. foldMap Sum >> >> sum' = getSum #. foldMap' Sum >> >> >> >> - Oleg >> >> >> >> On 18.10.2020 23.11, Hécate wrote: >> >>> >> >>> Indeed, and I initially went to suggest a >> >>> foldMap'`-based implementation to keep with the current >> >>> implementation of many Foldable functions that are based >> >>> on `foldMap` rather than a raw `fold`. >> >>> >> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >> >>>> For the sake of bigger audience I didn't bother >> >>>> mentioning #. which is a coercion helper. It's >> >>>> essentially better (.) when the first argument is >> >>>> newtype constructor (i.e. coerce). >> >>>> >> >>>> So with Option A (strict): >> >>>> >> >>>> sum = getSum #. foldMap' Sum >> >>>> >> >>>> Or Option B (lazy) >> >>>> >> >>>> sum = getSum #. foldMap Sum >> >>>> >> >>>> --- >> >>>> >> >>>> There is also third option, Option C: >> >>>> >> >>>> sum = foldr (+) 0 >> >>>> sum' = foldl' (+) 0 >> >>>> >> >>>> I don't think this is worthwhile, but it is an option. >> >>>> (to rehash, I don't consider maintaining status quo to >> >>>> be an option at all). >> >>>> >> >>>> - Oleg >> >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >> >>>>> >> >>>>> It's >> >>>>> >> >>>>> sum = getSum #. foldMap Sum >> >>>>> >> >>>>> in base. >> >>>>> >> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >> >>>>>> >> >>>>>> The problem is the current definition of sum for lists >> >>>>>> which uses foldl, i.e non-strict left fold >> >>>>>> >> >>>>>> sum = foldl (+) 0 >> >>>>>> >> >>>>>> It's utterly broken. Either we should change it to >> >>>>>> foldl' to work on some types where addition is strict, >> >>>>>> Option A: >> >>>>>> >> >>>>>> sum = foldl' (+) 0 >> >>>>>> >> >>>>>> or alternatively (to make people using lazy >> >>>>>> accumulator types), Option B: >> >>>>>> >> >>>>>> sum = foldr (+) 0 >> >>>>>> >> >>>>>> The current state is no good for anyone or anything. >> >>>>>> >> >>>>>> --- >> >>>>>> >> >>>>>> Related issue which Hecate didn't clearly mention, is >> >>>>>> that Foldable class default implementation has >> >>>>>> >> >>>>>> class Foldable f where >> >>>>>> ... >> >>>>>> sum = getSum . foldMap Sum -- this is "good" lazy definition >> >>>>>> >> >>>>>> If we select option A, then I argue that for >> >>>>>> consistency the default `Foldable.sum` should be >> >>>>>> >> >>>>>> sum = getSum . foldMap' Sum -- strict foldMap' >> >>>>>> >> >>>>>> If we select option B, Foldable definition doesn't need to be >> changed. >> >>>>>> >> >>>>>> --- >> >>>>>> >> >>>>>> I repeat, using non-strict left fold, foldl, for sum >> >>>>>> and product is not good for anything. >> >>>>>> Either foldr or foldl'. >> >>>>>> >> >>>>>> I have no strong preference. Current state is unacceptable. >> >>>>>> >> >>>>>> - Oleg >> >>>>>> >> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >> >>>>>>> >> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >> >>>>>>> >> >>>>>>>> In conclusion, leaving things to the optimiser that >> >>>>>>>> could be trivially made fast every time seems >> >>>>>>>> needlessly risky. >> >>>>>>> >> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' >> >>>>>>> would still fail on a lazy accumulator type, say a >> >>>>>>> lazy pair type. If at all, sum and product should be >> >>>>>>> deepseq-strict. So currently, letting the optimiser >> >>>>>>> make a lazy sum strict is still the smaller hack. >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Libraries mailing list >> >>>>>>> Libraries at haskell.org >> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Libraries mailing list >> >>>>>> Libraries at haskell.org >> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Libraries mailing list >> >>>>> Libraries at haskell.org >> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>>> >> >>>> _______________________________________________ >> >>>> Libraries mailing list >> >>>> Libraries at haskell.org >> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>> -- >> >>> Hécate ✨ >> >>> IRC: Uniaika >> >>> WWW:https://glitchbra.in >> >>> RUN: BSD >> >>> >> >>> _______________________________________________ >> >>> Libraries mailing list >> >>> Libraries at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -- >> Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk >> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05) >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Tue Oct 27 01:12:56 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Tue, 27 Oct 2020 01:12:56 +0000 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Just to keep this going so it doesn't die out. I'm going to request that Hécate submit a PR to address the composite criticism here, implementing `sum|product` in terms of `foldr`, and providing a strict equivalent `sum'|product'` variant for each as discussed. We'll move the discussion to that PR. Cheers, Emily On Thu, Oct 22, 2020 at 7:05 AM, Fumiaki Kinoshita < fumiexcel at gmail.com > wrote: > > >> For a forced example, consider a wrapping of Double with a test >> for infinity on the left argument >> >> … >> a + b | isInfinite a = a >> … >> > > > > This makes sense only if sum is foldr (+) 0, while the implementation of > sum for lists is foldl (+) 0. But hey, we are comparing a hypothetical > type with hundreds of real world uses. > > > > >> Haskell should remain a lazy language >> > > I'm not sure if I agree. We've been bitten by laziness too much, hence the > introduction of BangPatterns, StrictData, deepseq, etc. IMO Haskell > ecosystem should be more strict. > > > >> I'm uncomfortable with making foldMap/sum strict. >> > > > > No one is suggesting to change foldMap; what OP wants to change is sum and > product, and foldMap _happens to be_ the current default implementation. > > > >> > we dont knowing the context. the best way to avoid the cost of >> computation is not to compute it; what alternatives are there >> i this s[ecific problem. >> > > > > The context is pretty clear; the status quo (sum = foldl (+) 0) is > flat-out wrong. I'd say more than 80% of the uses of sum is supposed to > look at all the elements. And even if (+) is short-circuiting in the way > Jon suggested, lazy foldl does not take any advantage of it. > > > >> if one was to make foldMap/sum strict why not also other functions, e.g. >> scanAccum, where does one stop on the grounds of possibly saving costs in >> so as yet >> unknown application >> > > I'm not sure which function you are talking about (there's no function > called scanAccum in base nor containers). If you mean scanl, lazy > accumulator still makes sense because the resulting list can be consumed > incrementally. foldl is not. > > > > >> Instead of thinking/programming  in a pure lazy language, you are then in >> the position of thinking lazily apart from some set of >> to be determined exceptional cases. the simplicity and uniformity of the >> model is gone. >> > > Again, there's little to be gained from lazy foldl. It's avoided in > general and I'd say it's not "uniform" to use the function. > > > >> 4. As per item 3 but from a pedagogical point of view. I taught UG  FP for >> years. Complicating the model is not going to help students, >> to say nothing of the caveats that would have to be added to existing >> teaching materials. >> > > Also from a pedagogical point of view, a number of beginners fall into a > trap of lazy foldl. Caveats should be added to the current one if at all, > but this danger zone can be removed with one byte change. > > > I'm seriously worried that the use of foldl in the standard library might > make beginners think that it's fine to use foldl. > > > As far as I remember, the same change has been suggested a while ago but > didn't make it. I hope we don't get discouraged this time and go ahead > with the change. > > > > 2020年10月22日(木) 19:19 David Duke < duke. j. david@ gmail. com ( > duke.j.david at gmail.com ) >: > > >> Concur with Jon's point. >> I'm uncomfortable with making foldMap/sum strict. >> Haskell was intended to explore a region of the programming design space >> that had not been well covered. and it remains >> if not unique  then at least exemplary in that respect. When  I write in >> Haskell I do so with the knowledge that I am working with >> lazy evaluation with the benefits and risk that comes with that. If I'm >> desperate to have finer operational control, I  either >> swallow that pill and adapt my use of Haskell accordingly, or pick up a >> different tool from the programming language toolbox. >> >> >> Now the OP pointed to an issue with one specific use of sum. However, that >> seems like weak grounds to make library changes: >> 1. we dont knowing the context. the best way to avoid the cost of >> computation is not to compute it; what alternatives are there >> i this s[ecific problem. >> 2. if one was to make foldMap/sum strict why not also other functions, >> e.g. scanAccum, where does one stop on the grounds of possibly saving >> costs in so as yet >> unknown application >> 3. Instead of thinking/programming  in a pure lazy language, you are then >> in the position of thinking lazily apart from some set of >> to be determined exceptional cases. the simplicity and uniformity of the >> model is gone. >> 4. As per item 3 but from a pedagogical point of view. I taught UG  FP for >> years. Complicating the model is not going to help students, >> to say nothing of the caveats that would have to be added to existing >> teaching materials. >> So whilst  the post was clearly intended to trigger discussion, in terms >> on conveying sentiment a strict  foldMap would be a big '-' >> for me personally. Whilst there are performance challenges in working >> with Haskell. The primary role of the programming notation >> is allowing one to think about the problem and obtain a clear, correct >> solution. Performance tuning comes later if at all, and >> her are known techniques for doing so  with Haskell/ghc. >> 5. OTOH I see little   harm in adding a library that provides a strict >> foldMap for those >> who want to use it after  deliberate thought. >> >> >> YMMMocV >> David >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn < jon. fairbairn@ cl. cam. ac. >> uk ( jon.fairbairn at cl.cam.ac.uk ) > wrote: >> >> >>> Sylvain Henry < sylvain@ haskus. fr ( sylvain at haskus.fr ) > writes: >>> >>> > Do we have an actual example of the use of a lazy sum in the >>> > wild? >>> >>> That’s not a very good argument, though I’ve seen it used quite >>> a lot.  The problem is that just because no-one can currently >>> think of a “real” example it doesn’t mean that there are no >>> cases where laziness is required. >>> >>> For a forced example, consider a wrapping of Double with a test >>> for infinity on the left argument >>> >>> … >>> a + b | isInfinite a = a >>> … >>> >>> which doesn’t evaluate it’s second argument if the first is >>> infinite. >>> >>> > If the most common case is the strict one, making `sum` >>> > strict would be a better default. >>> >>> Haskell should remain a lazy language, so the defaults should be >>> lazy unless they can be proved strict anyway. >>> >>> > If need be we could also provide `lazySum` or something, but >>> > is there really a need? >>> >>> Who can truly say? I’d support sum' as the strict version as >>> that is consistent with other usages. >>> >>> — Jón >>> >>> > >>> > Sylvain >>> > >>> > >>> > On 18/10/2020 22:16, Oleg Grenrus wrote: >>> >> >>> >> Sorry I wasn't clear myself. Option C is "add sum'" >>> >> >>> >> For lists: >>> >> >>> >>     sum  = foldr  (+) 0 >>> >>     sum' = foldl' (+) 0 >>> >> >>> >> For Foldable >>> >> >>> >>     sum  = getSum #. foldMap  Sum >>> >>     sum' = getSum #. foldMap' Sum >>> >> >>> >> - Oleg >>> >> >>> >> On 18.10.2020 23.11, Hécate wrote: >>> >>> >>> >>> Indeed, and I initially went to suggest a >>> >>> foldMap'`-based implementation to keep with the current >>> >>> implementation of many Foldable functions that are based >>> >>> on `foldMap` rather than a raw `fold`. >>> >>> >>> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>> >>>> For the sake of bigger audience I didn't bother >>> >>>> mentioning #. which is a coercion helper. It's >>> >>>> essentially better (.) when the first argument is >>> >>>> newtype constructor (i.e. coerce). >>> >>>> >>> >>>> So with Option A (strict): >>> >>>> >>> >>>>     sum = getSum #. foldMap' Sum >>> >>>> >>> >>>> Or Option B (lazy) >>> >>>> >>> >>>>     sum = getSum #. foldMap Sum >>> >>>> >>> >>>> --- >>> >>>> >>> >>>> There is also third option, Option C: >>> >>>> >>> >>>>     sum  = foldr  (+) 0 >>> >>>>     sum' = foldl' (+) 0 >>> >>>> >>> >>>> I don't think this is worthwhile, but it is an option. >>> >>>> (to rehash, I don't consider maintaining status quo to >>> >>>> be an option at all). >>> >>>> >>> >>>> - Oleg >>> >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >>> >>>>> >>> >>>>> It's >>> >>>>> >>> >>>>> sum = getSum #. foldMap Sum >>> >>>>> >>> >>>>> in base. >>> >>>>> >>> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>> >>>>>> >>> >>>>>> The problem is the current definition of sum for lists >>> >>>>>> which uses foldl, i.e non-strict left fold >>> >>>>>> >>> >>>>>>     sum = foldl (+) 0 >>> >>>>>> >>> >>>>>> It's utterly broken. Either we should change it to >>> >>>>>> foldl' to work on some types where addition is strict, >>> >>>>>> Option A: >>> >>>>>> >>> >>>>>>     sum = foldl' (+) 0 >>> >>>>>> >>> >>>>>> or alternatively (to make people using lazy >>> >>>>>> accumulator types), Option B: >>> >>>>>> >>> >>>>>>     sum = foldr (+) 0 >>> >>>>>> >>> >>>>>> The current state is no good for anyone or anything. >>> >>>>>> >>> >>>>>> --- >>> >>>>>> >>> >>>>>> Related issue which Hecate didn't clearly mention, is >>> >>>>>> that Foldable class default implementation has >>> >>>>>> >>> >>>>>>    class Foldable f where >>> >>>>>>        ... >>> >>>>>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>> >>> >>>>>> >>> >>>>>> If we select option A, then I argue that for >>> >>>>>> consistency the default `Foldable.sum` should be >>> >>>>>> >>> >>>>>>        sum = getSum . foldMap' Sum -- strict foldMap' >>> >>>>>> >>> >>>>>> If we select option B, Foldable definition doesn't need to be >>> changed. >>> >>>>>> >>> >>>>>> --- >>> >>>>>> >>> >>>>>> I repeat, using non-strict left fold, foldl, for sum >>> >>>>>> and product is not good for anything. >>> >>>>>> Either foldr or foldl'. >>> >>>>>> >>> >>>>>> I have no strong preference. Current state is unacceptable. >>> >>>>>> >>> >>>>>> -  Oleg >>> >>>>>> >>> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>> >>>>>>> >>> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>> >>>>>>> >>> >>>>>>>> In conclusion, leaving things to the optimiser that >>> >>>>>>>> could be trivially made fast every time seems >>> >>>>>>>> needlessly risky. >>> >>>>>>> >>> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' >>> >>>>>>> would still fail on a lazy accumulator type, say a >>> >>>>>>> lazy pair type. If at all, sum and product should be >>> >>>>>>> deepseq-strict. So currently, letting the optimiser >>> >>>>>>> make a lazy sum strict is still the smaller hack. >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> Libraries mailing list >>> >>>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >>>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries >>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Libraries mailing list >>> >>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Libraries mailing list >>> >>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Libraries mailing list >>> >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>> -- >>> >>> Hécate ✨ >>> >>> IRC: Uniaika >>> >>> WWW: https:/ / glitchbra. in ( https://glitchbra.in ) >>> >>> RUN: BSD >>> >>> >>> >>> _______________________________________________ >>> >>> Libraries mailing list >>> >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >> >>> >> _______________________________________________ >>> >> Libraries mailing list >>> >> Libraries@ haskell. org ( Libraries at haskell.org ) >>> >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries@ haskell. org ( Libraries at haskell.org ) >>> > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>> -- >>> Jón Fairbairn Jon. Fairbairn@ cl. cam. ac. uk ( Jon.Fairbairn at cl.cam.ac.uk >>> ) >>> http:/ / www. chaos. org. uk/ ~jf/ Stuff-I-dont-want. html ( >>> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html ) (updated 2014-04-05) >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >> >> >> >> >> >> -- >> David Duke >> Emeritus Professor of Computer Science >> School of Computing University of Leeds UK >> E:duke. j. david@ gmail. com ( E%3Aduke.j.david at gmail.com ) >> W: https:/ / engineering. leeds. ac. uk/ staff/ 334/ Professor_David_Duke ( >> https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke ) >> _______________________________________________ >> Libraries mailing list >> Libraries@ haskell. org ( Libraries at haskell.org ) >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >> > > > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Tue Oct 27 01:16:09 2020 From: chessai1996 at gmail.com (chessai) Date: Mon, 26 Oct 2020 20:16:09 -0500 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Emily, I already put up an MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4355 On Mon, Oct 26, 2020, 20:14 Emily Pillmore wrote: > Just to keep this going so it doesn't die out. I'm going to request > that Hécate submit a PR to address the composite criticism here, > implementing `sum|product` in terms of `foldr`, and providing a strict > equivalent `sum'|product'` variant for each as discussed. We'll move the > discussion to that PR. > > Cheers, > Emily > > > On Thu, Oct 22, 2020 at 7:05 AM, Fumiaki Kinoshita > wrote: > >> For a forced example, consider a wrapping of Double with a test >>> for infinity on the left argument >>> >>> … >>> a + b | isInfinite a = a >>> … >>> >> >> This makes sense only if sum is foldr (+) 0, while the implementation of >> sum for lists is foldl (+) 0. But hey, we are comparing a hypothetical type >> with hundreds of real world uses. >> >> Haskell should remain a lazy language >>> >> I'm not sure if I agree. We've been bitten by laziness too much, hence >> the introduction of BangPatterns, StrictData, deepseq, etc. IMO Haskell >> ecosystem should be more strict. >> >> I'm uncomfortable with making foldMap/sum strict. >>> >> >> No one is suggesting to change foldMap; what OP wants to change is sum >> and product, and foldMap _happens to be_ the current default implementation. >> >> > we dont knowing the context. the best way to avoid the cost of >>> computation is not to compute it; what alternatives are there >>> i this s[ecific problem. >>> >> >> The context is pretty clear; the status quo (sum = foldl (+) 0) is >> flat-out wrong. I'd say more than 80% of the uses of sum is supposed to >> look at all the elements. And even if (+) is short-circuiting in the way >> Jon suggested, lazy foldl does not take any advantage of it. >> >> if one was to make foldMap/sum strict why not also other functions, e.g. >>> scanAccum, where does one stop on the grounds of possibly saving costs in >>> so as yet >>> unknown application >>> >> I'm not sure which function you are talking about (there's no function >> called scanAccum in base nor containers). If you mean scanl, lazy >> accumulator still makes sense because the resulting list can be consumed >> incrementally. foldl is not. >> >> Instead of thinking/programming in a pure lazy language, you are then in >>> the position of thinking lazily apart from some set of >>> to be determined exceptional cases. the simplicity and uniformity of the >>> model is gone. >>> >> Again, there's little to be gained from lazy foldl. It's avoided in >> general and I'd say it's not "uniform" to use the function. >> >> 4. As per item 3 but from a pedagogical point of view. I taught UG FP >>> for years. Complicating the model is not going to help students, >>> to say nothing of the caveats that would have to be added to >>> existing teaching materials. >>> >> Also from a pedagogical point of view, a number of beginners fall into a >> trap of lazy foldl. Caveats should be added to the current one if at all, >> but this danger zone can be removed with one byte change. >> >> I'm seriously worried that the use of foldl in the standard library might >> make beginners think that it's fine to use foldl. >> >> As far as I remember, the same change has been suggested a while ago but >> didn't make it. I hope we don't get discouraged this time and go ahead with >> the change. >> >> 2020年10月22日(木) 19:19 David Duke : >> >>> Concur with Jon's point. >>> I'm uncomfortable with making foldMap/sum strict. >>> Haskell was intended to explore a region of the programming design space >>> that had not been well covered. and it remains >>> if not unique then at least exemplary in that respect. When I write >>> in Haskell I do so with the knowledge that I am working with >>> lazy evaluation with the benefits and risk that comes with that. If I'm >>> desperate to have finer operational control, I either >>> swallow that pill and adapt my use of Haskell accordingly, or pick up a >>> different tool from the programming language toolbox. >>> >>> Now the OP pointed to an issue with one specific use of sum. However, >>> that seems like weak grounds to make library changes: >>> 1. we dont knowing the context. the best way to avoid the cost of >>> computation is not to compute it; what alternatives are there >>> i this s[ecific problem. >>> 2. if one was to make foldMap/sum strict why not also other functions, >>> e.g. scanAccum, where does one stop on the grounds of possibly saving costs >>> in so as yet >>> unknown application >>> 3. Instead of thinking/programming in a pure lazy language, you are >>> then in the position of thinking lazily apart from some set of >>> to be determined exceptional cases. the simplicity and uniformity of the >>> model is gone. >>> 4. As per item 3 but from a pedagogical point of view. I taught UG FP >>> for years. Complicating the model is not going to help students, >>> to say nothing of the caveats that would have to be added to >>> existing teaching materials. >>> So whilst the post was clearly intended to trigger discussion, in terms >>> on conveying sentiment a strict foldMap would be a big '-' >>> for me personally. Whilst there are performance challenges in working >>> with Haskell. The primary role of the programming notation >>> is allowing one to think about the problem and obtain a clear, correct >>> solution. Performance tuning comes later if at all, and >>> her are known techniques for doing so with Haskell/ghc. >>> 5. OTOH I see little harm in adding a library that provides a strict >>> foldMap for those >>> who want to use it after deliberate thought. >>> >>> YMMMocV >>> David >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn < >>> jon.fairbairn at cl.cam.ac.uk> wrote: >>> >>>> Sylvain Henry writes: >>>> >>>> > Do we have an actual example of the use of a lazy sum in the >>>> > wild? >>>> >>>> That’s not a very good argument, though I’ve seen it used quite >>>> a lot. The problem is that just because no-one can currently >>>> think of a “real” example it doesn’t mean that there are no >>>> cases where laziness is required. >>>> >>>> For a forced example, consider a wrapping of Double with a test >>>> for infinity on the left argument >>>> >>>> … >>>> a + b | isInfinite a = a >>>> … >>>> >>>> which doesn’t evaluate it’s second argument if the first is >>>> infinite. >>>> >>>> > If the most common case is the strict one, making `sum` >>>> > strict would be a better default. >>>> >>>> Haskell should remain a lazy language, so the defaults should be >>>> lazy unless they can be proved strict anyway. >>>> >>>> > If need be we could also provide `lazySum` or something, but >>>> > is there really a need? >>>> >>>> Who can truly say? I’d support sum' as the strict version as >>>> that is consistent with other usages. >>>> >>>> — Jón >>>> >>>> > >>>> > Sylvain >>>> > >>>> > >>>> > On 18/10/2020 22:16, Oleg Grenrus wrote: >>>> >> >>>> >> Sorry I wasn't clear myself. Option C is "add sum'" >>>> >> >>>> >> For lists: >>>> >> >>>> >> sum = foldr (+) 0 >>>> >> sum' = foldl' (+) 0 >>>> >> >>>> >> For Foldable >>>> >> >>>> >> sum = getSum #. foldMap Sum >>>> >> sum' = getSum #. foldMap' Sum >>>> >> >>>> >> - Oleg >>>> >> >>>> >> On 18.10.2020 23.11, Hécate wrote: >>>> >>> >>>> >>> Indeed, and I initially went to suggest a >>>> >>> foldMap'`-based implementation to keep with the current >>>> >>> implementation of many Foldable functions that are based >>>> >>> on `foldMap` rather than a raw `fold`. >>>> >>> >>>> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>>> >>>> For the sake of bigger audience I didn't bother >>>> >>>> mentioning #. which is a coercion helper. It's >>>> >>>> essentially better (.) when the first argument is >>>> >>>> newtype constructor (i.e. coerce). >>>> >>>> >>>> >>>> So with Option A (strict): >>>> >>>> >>>> >>>> sum = getSum #. foldMap' Sum >>>> >>>> >>>> >>>> Or Option B (lazy) >>>> >>>> >>>> >>>> sum = getSum #. foldMap Sum >>>> >>>> >>>> >>>> --- >>>> >>>> >>>> >>>> There is also third option, Option C: >>>> >>>> >>>> >>>> sum = foldr (+) 0 >>>> >>>> sum' = foldl' (+) 0 >>>> >>>> >>>> >>>> I don't think this is worthwhile, but it is an option. >>>> >>>> (to rehash, I don't consider maintaining status quo to >>>> >>>> be an option at all). >>>> >>>> >>>> >>>> - Oleg >>>> >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >>>> >>>>> >>>> >>>>> It's >>>> >>>>> >>>> >>>>> sum = getSum #. foldMap Sum >>>> >>>>> >>>> >>>>> in base. >>>> >>>>> >>>> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>> >>>>>> >>>> >>>>>> The problem is the current definition of sum for lists >>>> >>>>>> which uses foldl, i.e non-strict left fold >>>> >>>>>> >>>> >>>>>> sum = foldl (+) 0 >>>> >>>>>> >>>> >>>>>> It's utterly broken. Either we should change it to >>>> >>>>>> foldl' to work on some types where addition is strict, >>>> >>>>>> Option A: >>>> >>>>>> >>>> >>>>>> sum = foldl' (+) 0 >>>> >>>>>> >>>> >>>>>> or alternatively (to make people using lazy >>>> >>>>>> accumulator types), Option B: >>>> >>>>>> >>>> >>>>>> sum = foldr (+) 0 >>>> >>>>>> >>>> >>>>>> The current state is no good for anyone or anything. >>>> >>>>>> >>>> >>>>>> --- >>>> >>>>>> >>>> >>>>>> Related issue which Hecate didn't clearly mention, is >>>> >>>>>> that Foldable class default implementation has >>>> >>>>>> >>>> >>>>>> class Foldable f where >>>> >>>>>> ... >>>> >>>>>> sum = getSum . foldMap Sum -- this is "good" lazy >>>> definition >>>> >>>>>> >>>> >>>>>> If we select option A, then I argue that for >>>> >>>>>> consistency the default `Foldable.sum` should be >>>> >>>>>> >>>> >>>>>> sum = getSum . foldMap' Sum -- strict foldMap' >>>> >>>>>> >>>> >>>>>> If we select option B, Foldable definition doesn't need to be >>>> changed. >>>> >>>>>> >>>> >>>>>> --- >>>> >>>>>> >>>> >>>>>> I repeat, using non-strict left fold, foldl, for sum >>>> >>>>>> and product is not good for anything. >>>> >>>>>> Either foldr or foldl'. >>>> >>>>>> >>>> >>>>>> I have no strong preference. Current state is unacceptable. >>>> >>>>>> >>>> >>>>>> - Oleg >>>> >>>>>> >>>> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>> >>>>>>> >>>> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>> >>>>>>> >>>> >>>>>>>> In conclusion, leaving things to the optimiser that >>>> >>>>>>>> could be trivially made fast every time seems >>>> >>>>>>>> needlessly risky. >>>> >>>>>>> >>>> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' >>>> >>>>>>> would still fail on a lazy accumulator type, say a >>>> >>>>>>> lazy pair type. If at all, sum and product should be >>>> >>>>>>> deepseq-strict. So currently, letting the optimiser >>>> >>>>>>> make a lazy sum strict is still the smaller hack. >>>> >>>>>>> >>>> >>>>>>> _______________________________________________ >>>> >>>>>>> Libraries mailing list >>>> >>>>>>> Libraries at haskell.org >>>> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> Libraries mailing list >>>> >>>>>> Libraries at haskell.org >>>> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> Libraries mailing list >>>> >>>>> Libraries at haskell.org >>>> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Libraries mailing list >>>> >>>> Libraries at haskell.org >>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> -- >>>> >>> Hécate [image: ✨] >>>> >>> IRC: Uniaika >>>> >>> WWW:https://glitchbra.in >>>> >>> RUN: BSD >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Libraries mailing list >>>> >>> Libraries at haskell.org >>>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >> >>>> >> _______________________________________________ >>>> >> Libraries mailing list >>>> >> Libraries at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> > _______________________________________________ >>>> > Libraries mailing list >>>> > Libraries at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> -- >>>> Jón Fairbairn >>>> Jon.Fairbairn at cl.cam.ac.uk >>>> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated >>>> 2014-04-05) >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> >>> >>> -- >>> David Duke >>> Emeritus Professor of Computer Science >>> School of Computing University of Leeds UK >>> E:duke.j.david at gmail.com >>> W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Tue Oct 27 01:45:08 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Tue, 27 Oct 2020 01:45:08 +0000 Subject: [Proposal] Strict `sum` and `product` In-Reply-To: References: <390dbc99-abdc-2b00-366d-50cb4291380f@gmail.com> <035231ea-7187-f096-d5bc-29ffe752d41d@iki.fi> <77399542-9ab4-381a-a8ce-3ddfe518fb9a@glitchbra.in> <2fecff7d-1a18-5c94-5e90-27c80c7fae14@iki.fi> Message-ID: Nice, thanks Chessai On Mon, Oct 26, 2020 at 9:16 PM, chessai < chessai1996 at gmail.com > wrote: > > Emily, I already put up an MR: https:/ / gitlab. haskell. org/ ghc/ ghc/ -/ > merge_requests/ 4355 ( > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4355 ) > > On Mon, Oct 26, 2020, 20:14 Emily Pillmore < emilypi@ cohomolo. gy ( > emilypi at cohomolo.gy ) > wrote: > > >> Just to keep this going so it doesn't die out. I'm going to request that >> Hécate submit a PR to address the composite criticism here, implementing >> `sum|product` in terms of `foldr`, and providing a strict equivalent >> `sum'|product'` variant for each as discussed. We'll move the discussion >> to that PR. >> >> >> >> Cheers, >> >> Emily >> >> >> >> >> On Thu, Oct 22, 2020 at 7:05 AM, Fumiaki Kinoshita < fumiexcel@ gmail. com >> ( fumiexcel at gmail.com ) > wrote: >> >>> >>>> For a forced example, consider a wrapping of Double with a test >>>> for infinity on the left argument >>>> >>>> … >>>> a + b | isInfinite a = a >>>> … >>>> >>> >>> >>> >>> This makes sense only if sum is foldr (+) 0, while the implementation of >>> sum for lists is foldl (+) 0. But hey, we are comparing a hypothetical >>> type with hundreds of real world uses. >>> >>> >>> >>> >>>> Haskell should remain a lazy language >>>> >>> >>> I'm not sure if I agree. We've been bitten by laziness too much, hence the >>> introduction of BangPatterns, StrictData, deepseq, etc. IMO Haskell >>> ecosystem should be more strict. >>> >>> >>> >>>> I'm uncomfortable with making foldMap/sum strict. >>>> >>> >>> >>> >>> No one is suggesting to change foldMap; what OP wants to change is sum and >>> product, and foldMap _happens to be_ the current default implementation. >>> >>> >>> >>>> > we dont knowing the context. the best way to avoid the cost of >>>> computation is not to compute it; what alternatives are there >>>> i this s[ecific problem. >>>> >>> >>> >>> >>> The context is pretty clear; the status quo (sum = foldl (+) 0) is >>> flat-out wrong. I'd say more than 80% of the uses of sum is supposed to >>> look at all the elements. And even if (+) is short-circuiting in the way >>> Jon suggested, lazy foldl does not take any advantage of it. >>> >>> >>> >>>> if one was to make foldMap/sum strict why not also other functions, e.g. >>>> scanAccum, where does one stop on the grounds of possibly saving costs in >>>> so as yet >>>> unknown application >>>> >>> >>> I'm not sure which function you are talking about (there's no function >>> called scanAccum in base nor containers). If you mean scanl, lazy >>> accumulator still makes sense because the resulting list can be consumed >>> incrementally. foldl is not. >>> >>> >>> >>> >>>> Instead of thinking/programming  in a pure lazy language, you are then in >>>> the position of thinking lazily apart from some set of >>>> to be determined exceptional cases. the simplicity and uniformity of the >>>> model is gone. >>>> >>> >>> Again, there's little to be gained from lazy foldl. It's avoided in >>> general and I'd say it's not "uniform" to use the function. >>> >>> >>> >>>> 4. As per item 3 but from a pedagogical point of view. I taught UG  FP for >>>> years. Complicating the model is not going to help students, >>>> to say nothing of the caveats that would have to be added to existing >>>> teaching materials. >>>> >>> >>> Also from a pedagogical point of view, a number of beginners fall into a >>> trap of lazy foldl. Caveats should be added to the current one if at all, >>> but this danger zone can be removed with one byte change. >>> >>> >>> I'm seriously worried that the use of foldl in the standard library might >>> make beginners think that it's fine to use foldl. >>> >>> >>> As far as I remember, the same change has been suggested a while ago but >>> didn't make it. I hope we don't get discouraged this time and go ahead >>> with the change. >>> >>> >>> >>> 2020年10月22日(木) 19:19 David Duke < duke. j. david@ gmail. com ( >>> duke.j.david at gmail.com ) >: >>> >>> >>>> Concur with Jon's point. >>>> I'm uncomfortable with making foldMap/sum strict. >>>> Haskell was intended to explore a region of the programming design space >>>> that had not been well covered. and it remains >>>> if not unique  then at least exemplary in that respect. When  I write in >>>> Haskell I do so with the knowledge that I am working with >>>> lazy evaluation with the benefits and risk that comes with that. If I'm >>>> desperate to have finer operational control, I  either >>>> swallow that pill and adapt my use of Haskell accordingly, or pick up a >>>> different tool from the programming language toolbox. >>>> >>>> >>>> Now the OP pointed to an issue with one specific use of sum. However, that >>>> seems like weak grounds to make library changes: >>>> 1. we dont knowing the context. the best way to avoid the cost of >>>> computation is not to compute it; what alternatives are there >>>> i this s[ecific problem. >>>> 2. if one was to make foldMap/sum strict why not also other functions, >>>> e.g. scanAccum, where does one stop on the grounds of possibly saving >>>> costs in so as yet >>>> unknown application >>>> 3. Instead of thinking/programming  in a pure lazy language, you are then >>>> in the position of thinking lazily apart from some set of >>>> to be determined exceptional cases. the simplicity and uniformity of the >>>> model is gone. >>>> 4. As per item 3 but from a pedagogical point of view. I taught UG  FP for >>>> years. Complicating the model is not going to help students, >>>> to say nothing of the caveats that would have to be added to existing >>>> teaching materials. >>>> So whilst  the post was clearly intended to trigger discussion, in terms >>>> on conveying sentiment a strict  foldMap would be a big '-' >>>> for me personally. Whilst there are performance challenges in working >>>> with Haskell. The primary role of the programming notation >>>> is allowing one to think about the problem and obtain a clear, correct >>>> solution. Performance tuning comes later if at all, and >>>> her are known techniques for doing so  with Haskell/ghc. >>>> 5. OTOH I see little   harm in adding a library that provides a strict >>>> foldMap for those >>>> who want to use it after  deliberate thought. >>>> >>>> >>>> YMMMocV >>>> David >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Oct 22, 2020 at 10:36 AM Jon Fairbairn < jon. fairbairn@ cl. cam. ac. >>>> uk ( jon.fairbairn at cl.cam.ac.uk ) > wrote: >>>> >>>> >>>>> Sylvain Henry < sylvain@ haskus. fr ( sylvain at haskus.fr ) > writes: >>>>> >>>>> > Do we have an actual example of the use of a lazy sum in the >>>>> > wild? >>>>> >>>>> That’s not a very good argument, though I’ve seen it used quite >>>>> a lot.  The problem is that just because no-one can currently >>>>> think of a “real” example it doesn’t mean that there are no >>>>> cases where laziness is required. >>>>> >>>>> For a forced example, consider a wrapping of Double with a test >>>>> for infinity on the left argument >>>>> >>>>> … >>>>> a + b | isInfinite a = a >>>>> … >>>>> >>>>> which doesn’t evaluate it’s second argument if the first is >>>>> infinite. >>>>> >>>>> > If the most common case is the strict one, making `sum` >>>>> > strict would be a better default. >>>>> >>>>> Haskell should remain a lazy language, so the defaults should be >>>>> lazy unless they can be proved strict anyway. >>>>> >>>>> > If need be we could also provide `lazySum` or something, but >>>>> > is there really a need? >>>>> >>>>> Who can truly say? I’d support sum' as the strict version as >>>>> that is consistent with other usages. >>>>> >>>>> — Jón >>>>> >>>>> > >>>>> > Sylvain >>>>> > >>>>> > >>>>> > On 18/10/2020 22:16, Oleg Grenrus wrote: >>>>> >> >>>>> >> Sorry I wasn't clear myself. Option C is "add sum'" >>>>> >> >>>>> >> For lists: >>>>> >> >>>>> >>     sum  = foldr  (+) 0 >>>>> >>     sum' = foldl' (+) 0 >>>>> >> >>>>> >> For Foldable >>>>> >> >>>>> >>     sum  = getSum #. foldMap  Sum >>>>> >>     sum' = getSum #. foldMap' Sum >>>>> >> >>>>> >> - Oleg >>>>> >> >>>>> >> On 18.10.2020 23.11, Hécate wrote: >>>>> >>> >>>>> >>> Indeed, and I initially went to suggest a >>>>> >>> foldMap'`-based implementation to keep with the current >>>>> >>> implementation of many Foldable functions that are based >>>>> >>> on `foldMap` rather than a raw `fold`. >>>>> >>> >>>>> >>> On 18/10/2020 22:04, Oleg Grenrus wrote: >>>>> >>>> For the sake of bigger audience I didn't bother >>>>> >>>> mentioning #. which is a coercion helper. It's >>>>> >>>> essentially better (.) when the first argument is >>>>> >>>> newtype constructor (i.e. coerce). >>>>> >>>> >>>>> >>>> So with Option A (strict): >>>>> >>>> >>>>> >>>>     sum = getSum #. foldMap' Sum >>>>> >>>> >>>>> >>>> Or Option B (lazy) >>>>> >>>> >>>>> >>>>     sum = getSum #. foldMap Sum >>>>> >>>> >>>>> >>>> --- >>>>> >>>> >>>>> >>>> There is also third option, Option C: >>>>> >>>> >>>>> >>>>     sum  = foldr  (+) 0 >>>>> >>>>     sum' = foldl' (+) 0 >>>>> >>>> >>>>> >>>> I don't think this is worthwhile, but it is an option. >>>>> >>>> (to rehash, I don't consider maintaining status quo to >>>>> >>>> be an option at all). >>>>> >>>> >>>>> >>>> - Oleg >>>>> >>>> On 18.10.2020 22.54, Vanessa McHale wrote: >>>>> >>>>> >>>>> >>>>> It's >>>>> >>>>> >>>>> >>>>> sum = getSum #. foldMap Sum >>>>> >>>>> >>>>> >>>>> in base. >>>>> >>>>> >>>>> >>>>> On 10/18/20 2:49 PM, Oleg Grenrus wrote: >>>>> >>>>>> >>>>> >>>>>> The problem is the current definition of sum for lists >>>>> >>>>>> which uses foldl, i.e non-strict left fold >>>>> >>>>>> >>>>> >>>>>>     sum = foldl (+) 0 >>>>> >>>>>> >>>>> >>>>>> It's utterly broken. Either we should change it to >>>>> >>>>>> foldl' to work on some types where addition is strict, >>>>> >>>>>> Option A: >>>>> >>>>>> >>>>> >>>>>>     sum = foldl' (+) 0 >>>>> >>>>>> >>>>> >>>>>> or alternatively (to make people using lazy >>>>> >>>>>> accumulator types), Option B: >>>>> >>>>>> >>>>> >>>>>>     sum = foldr (+) 0 >>>>> >>>>>> >>>>> >>>>>> The current state is no good for anyone or anything. >>>>> >>>>>> >>>>> >>>>>> --- >>>>> >>>>>> >>>>> >>>>>> Related issue which Hecate didn't clearly mention, is >>>>> >>>>>> that Foldable class default implementation has >>>>> >>>>>> >>>>> >>>>>>    class Foldable f where >>>>> >>>>>>        ... >>>>> >>>>>>        sum = getSum . foldMap Sum -- this is "good" lazy definition >>>>> >>>>> >>>>>> >>>>> >>>>>> If we select option A, then I argue that for >>>>> >>>>>> consistency the default `Foldable.sum` should be >>>>> >>>>>> >>>>> >>>>>>        sum = getSum . foldMap' Sum -- strict foldMap' >>>>> >>>>>> >>>>> >>>>>> If we select option B, Foldable definition doesn't need to be >>>>> changed. >>>>> >>>>>> >>>>> >>>>>> --- >>>>> >>>>>> >>>>> >>>>>> I repeat, using non-strict left fold, foldl, for sum >>>>> >>>>>> and product is not good for anything. >>>>> >>>>>> Either foldr or foldl'. >>>>> >>>>>> >>>>> >>>>>> I have no strong preference. Current state is unacceptable. >>>>> >>>>>> >>>>> >>>>>> -  Oleg >>>>> >>>>>> >>>>> >>>>>> On 18.10.2020 22.24, Henning Thielemann wrote: >>>>> >>>>>>> >>>>> >>>>>>> On Sun, 18 Oct 2020, Hécate wrote: >>>>> >>>>>>> >>>>> >>>>>>>> In conclusion, leaving things to the optimiser that >>>>> >>>>>>>> could be trivially made fast every time seems >>>>> >>>>>>>> needlessly risky. >>>>> >>>>>>> >>>>> >>>>>>> `seq` is still a hack. A strict 'sum' and 'product' >>>>> >>>>>>> would still fail on a lazy accumulator type, say a >>>>> >>>>>>> lazy pair type. If at all, sum and product should be >>>>> >>>>>>> deepseq-strict. So currently, letting the optimiser >>>>> >>>>>>> make a lazy sum strict is still the smaller hack. >>>>> >>>>>>> >>>>> >>>>>>> _______________________________________________ >>>>> >>>>>>> Libraries mailing list >>>>> >>>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >>>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries >>>>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> Libraries mailing list >>>>> >>>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> Libraries mailing list >>>>> >>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> Libraries mailing list >>>>> >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>> -- >>>>> >>> Hécate ✨ >>>>> >>> IRC: Uniaika >>>>> >>> WWW: https:/ / glitchbra. in ( https://glitchbra.in ) >>>>> >>> RUN: BSD >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> Libraries mailing list >>>>> >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >> >>>>> >> _______________________________________________ >>>>> >> Libraries mailing list >>>>> >> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> > _______________________________________________ >>>>> > Libraries mailing list >>>>> > Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>>> -- >>>>> Jón Fairbairn Jon. Fairbairn@ cl. cam. ac. uk ( Jon.Fairbairn at cl.cam.ac.uk >>>>> ) >>>>> http:/ / www. chaos. org. uk/ ~jf/ Stuff-I-dont-want. html ( >>>>> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html ) (updated 2014-04-05) >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> David Duke >>>> Emeritus Professor of Computer Science >>>> School of Computing University of Leeds UK >>>> E:duke. j. david@ gmail. com ( E%3Aduke.j.david at gmail.com ) >>>> W: https:/ / engineering. leeds. ac. uk/ staff/ 334/ Professor_David_Duke ( >>>> https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke ) >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>> >>> >>> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@ haskell. org ( Libraries at haskell.org ) >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclhiannan at gmail.com Thu Oct 29 11:35:33 2020 From: sclhiannan at gmail.com (Sean Chalmers) Date: Thu, 29 Oct 2020 11:35:33 +0000 Subject: Stepping away Message-ID: Hi all, For various reasons I'm not interested in maintaining my Haskell packages any more. If anyone has any interest in taking over then I am happy to hand them over: async-io-either classy-influxdb-simple haskell-time-range hoist-error reflex-dom-svg servant-waargonaut tasty-hedgehog-coverage tasty-wai waargonaut Been swell, swellings gone down. Cheers, Sean Chalmers -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Thu Oct 29 14:32:17 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Thu, 29 Oct 2020 14:32:17 +0000 Subject: Stepping away In-Reply-To: References: Message-ID: Hey Sean, I'm sad to see you go and I hope everything is okay :(((( I'd love to keep waargonaut going, as well as `servant-waargonaut`. I'm also happy to turn them back over if you end up coming back. craawwwwwling innnnn my skiiiiiiin, Emily On Thu, Oct 29, 2020 at 7:35 AM, Sean Chalmers < sclhiannan at gmail.com > wrote: > > Hi all, > > > For various reasons I'm not interested in maintaining my Haskell packages > any more. If anyone has any interest in taking over then I am happy to > hand them over: > > > async-io-either > classy-influxdb-simple > haskell-time-range > hoist-error > reflex-dom-svg > servant-waargonaut > tasty-hedgehog-coverage > tasty-wai > waargonaut > > > > Been swell, swellings gone down. > > > Cheers, > > > Sean Chalmers > > > _______________________________________________ > Libraries mailing list > Libraries@ haskell. org ( Libraries at haskell.org ) > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclhiannan at gmail.com Thu Oct 29 15:45:20 2020 From: sclhiannan at gmail.com (Sean Chalmers) Date: Thu, 29 Oct 2020 15:45:20 +0000 Subject: Stepping away In-Reply-To: References: Message-ID: Hi Emily, It's a bummer, but like a lot of people life is being very lifelike at the moment and I just don't have the spoons. :( I am super happy you're keen on keeping the Waarg going. I'm not sure what deets I need from you to transfer ownership? Cheers, Sean On Thu, 29 Oct 2020 at 14:32, Emily Pillmore wrote: > Hey Sean, > > I'm sad to see you go and I hope everything is okay :(((( > > I'd love to keep waargonaut going, as well as `servant-waargonaut`. I'm > also happy to turn them back over if you end up coming back. > > craawwwwwling innnnn my skiiiiiiin, > Emily > > > On Thu, Oct 29, 2020 at 7:35 AM, Sean Chalmers > wrote: > >> Hi all, >> >> For various reasons I'm not interested in maintaining my Haskell packages >> any more. If anyone has any interest in taking over then I am happy to hand >> them over: >> >> async-io-either >> classy-influxdb-simple >> haskell-time-range >> hoist-error >> reflex-dom-svg >> servant-waargonaut >> tasty-hedgehog-coverage >> tasty-wai >> waargonaut >> >> Been swell, swellings gone down. >> >> Cheers, >> >> Sean Chalmers >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Oct 29 23:15:56 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 29 Oct 2020 19:15:56 -0400 Subject: Stepping away In-Reply-To: References: Message-ID: Indeed, it’s a hard year and emily has really good taste, I trust her to keep the waargonaut kiln warm for you. It’s a darn nice lib for those who aren’t familiar. https://hackage.haskell.org/package/waargonaut On Thu, Oct 29, 2020 at 11:46 AM Sean Chalmers wrote: > Hi Emily, > > It's a bummer, but like a lot of people life is being very lifelike at the > moment and I just don't have the spoons. :( > > I am super happy you're keen on keeping the Waarg going. I'm not sure what > deets I need from you to transfer ownership? > > Cheers, > > Sean > > On Thu, 29 Oct 2020 at 14:32, Emily Pillmore wrote: > >> Hey Sean, >> >> I'm sad to see you go and I hope everything is okay :(((( >> >> I'd love to keep waargonaut going, as well as `servant-waargonaut`. I'm >> also happy to turn them back over if you end up coming back. >> >> craawwwwwling innnnn my skiiiiiiin, >> Emily >> >> >> On Thu, Oct 29, 2020 at 7:35 AM, Sean Chalmers >> wrote: >> >>> Hi all, >>> >>> For various reasons I'm not interested in maintaining my Haskell >>> packages any more. If anyone has any interest in taking over then I am >>> happy to hand them over: >>> >>> async-io-either >>> classy-influxdb-simple >>> haskell-time-range >>> hoist-error >>> reflex-dom-svg >>> servant-waargonaut >>> tasty-hedgehog-coverage >>> tasty-wai >>> waargonaut >>> >>> Been swell, swellings gone down. >>> >>> Cheers, >>> >>> Sean Chalmers >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Fri Oct 30 00:44:00 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 30 Oct 2020 00:44:00 +0000 Subject: Stepping away In-Reply-To: References: Message-ID: I'm waargohot for waargonaut. On Thu, Oct 29, 2020 at 7:15 PM, Carter Schonwald < carter.schonwald at gmail.com > wrote: > > Indeed, it’s a hard year and emily has really good taste, I trust her to > keep the waargonaut kiln warm for you. > > > It’s a darn nice lib for those who aren’t familiar. > https:/ / hackage. haskell. org/ package/ waargonaut ( > https://hackage.haskell.org/package/waargonaut ) > > > > On Thu, Oct 29, 2020 at 11:46 AM Sean Chalmers < sclhiannan@ gmail. com ( > sclhiannan at gmail.com ) > wrote: > > >> Hi Emily, >> >> >> It's a bummer, but like a lot of people life is being very lifelike at the >> moment and I just don't have the spoons. :( >> >> >> I am super happy you're keen on keeping the Waarg going. I'm not sure what >> deets I need from you to transfer ownership? >> >> >> Cheers, >> >> >> Sean >> >> On Thu, 29 Oct 2020 at 14:32, Emily Pillmore < emilypi@ cohomolo. gy ( >> emilypi at cohomolo.gy ) > wrote: >> >> >>> Hey Sean, >>> >>> >>> >>> I'm sad to see you go and I hope everything is okay :(((( >>> >>> >>> >>> I'd love to keep waargonaut going, as well as `servant-waargonaut`. I'm >>> also happy to turn them back over if you end up coming back. >>> >>> >>> >>> craawwwwwling innnnn my skiiiiiiin, >>> >>> Emily >>> >>> >>> >>> On Thu, Oct 29, 2020 at 7:35 AM, Sean Chalmers < sclhiannan@ gmail. com ( >>> sclhiannan at gmail.com ) > wrote: >>> >>>> Hi all, >>>> >>>> >>>> For various reasons I'm not interested in maintaining my Haskell packages >>>> any more. If anyone has any interest in taking over then I am happy to >>>> hand them over: >>>> >>>> >>>> async-io-either >>>> classy-influxdb-simple >>>> haskell-time-range >>>> hoist-error >>>> reflex-dom-svg >>>> servant-waargonaut >>>> tasty-hedgehog-coverage >>>> tasty-wai >>>> waargonaut >>>> >>>> >>>> >>>> Been swell, swellings gone down. >>>> >>>> >>>> Cheers, >>>> >>>> >>>> Sean Chalmers >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@ haskell. org ( Libraries at haskell.org ) >>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >>>> >>>> >>>> >>> >>> >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@ haskell. org ( Libraries at haskell.org ) >> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclhiannan at gmail.com Fri Oct 30 08:22:18 2020 From: sclhiannan at gmail.com (Sean Chalmers) Date: Fri, 30 Oct 2020 08:22:18 +0000 Subject: Stepping away In-Reply-To: References: Message-ID: Thank you both, tis greatly appreciated. On Thu, 29 Oct 2020 at 23:16, Carter Schonwald wrote: > Indeed, it’s a hard year and emily has really good taste, I trust her to > keep the waargonaut kiln warm for you. > > It’s a darn nice lib for those who aren’t familiar. > https://hackage.haskell.org/package/waargonaut > > > On Thu, Oct 29, 2020 at 11:46 AM Sean Chalmers > wrote: > >> Hi Emily, >> >> It's a bummer, but like a lot of people life is being very lifelike at >> the moment and I just don't have the spoons. :( >> >> I am super happy you're keen on keeping the Waarg going. I'm not sure >> what deets I need from you to transfer ownership? >> >> Cheers, >> >> Sean >> >> On Thu, 29 Oct 2020 at 14:32, Emily Pillmore wrote: >> >>> Hey Sean, >>> >>> I'm sad to see you go and I hope everything is okay :(((( >>> >>> I'd love to keep waargonaut going, as well as `servant-waargonaut`. I'm >>> also happy to turn them back over if you end up coming back. >>> >>> craawwwwwling innnnn my skiiiiiiin, >>> Emily >>> >>> >>> On Thu, Oct 29, 2020 at 7:35 AM, Sean Chalmers >>> wrote: >>> >>>> Hi all, >>>> >>>> For various reasons I'm not interested in maintaining my Haskell >>>> packages any more. If anyone has any interest in taking over then I am >>>> happy to hand them over: >>>> >>>> async-io-either >>>> classy-influxdb-simple >>>> haskell-time-range >>>> hoist-error >>>> reflex-dom-svg >>>> servant-waargonaut >>>> tasty-hedgehog-coverage >>>> tasty-wai >>>> waargonaut >>>> >>>> Been swell, swellings gone down. >>>> >>>> Cheers, >>>> >>>> Sean Chalmers >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> >>> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Fri Oct 30 17:53:36 2020 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Fri, 30 Oct 2020 18:53:36 +0100 Subject: Stepping away In-Reply-To: References: Message-ID: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> Hi Sean, On 29/10/2020 16:45, Sean Chalmers wrote: > I'm not sure what deets I need from you to transfer ownership? Usually you'd add your co-maintainers to the maintainers list under https://hackage.haskell.org/package/YOUR_PACKAGE_NAME/maintainers/ and give them push access to whatever version control you use for the package (e.g. Github). Cheers, Niklas From david.feuer at gmail.com Fri Oct 30 17:56:43 2020 From: david.feuer at gmail.com (David Feuer) Date: Fri, 30 Oct 2020 13:56:43 -0400 Subject: Stepping away In-Reply-To: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> References: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> Message-ID: Ask Emily to create a GitHub "organization" and transfer ownership of the repository to that organization. Organizations are good because they can have multiple owners—redundancy is nice. Transferring the whole repository will also transfer all issues and pull requests. On Fri, Oct 30, 2020, 1:54 PM Niklas Hambüchen via Libraries < libraries at haskell.org> wrote: > Hi Sean, > > On 29/10/2020 16:45, Sean Chalmers wrote: > > I'm not sure what deets I need from you to transfer ownership? > > Usually you'd add your co-maintainers to the maintainers list under > > https://hackage.haskell.org/package/YOUR_PACKAGE_NAME/maintainers/ > > and give them push access to whatever version control you use for the > package (e.g. Github). > > Cheers, > Niklas > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclhiannan at gmail.com Fri Oct 30 17:57:37 2020 From: sclhiannan at gmail.com (Sean Chalmers) Date: Fri, 30 Oct 2020 17:57:37 +0000 Subject: Stepping away In-Reply-To: References: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> Message-ID: Agreed, orgs are good. We've a bit of logistics to sort for the repo but apart from that it's all sorted now. Thanks for the tips. :) On Fri, 30 Oct 2020 at 17:56, David Feuer wrote: > Ask Emily to create a GitHub "organization" and transfer ownership of the > repository to that organization. Organizations are good because they can > have multiple owners—redundancy is nice. Transferring the whole repository > will also transfer all issues and pull requests. > > On Fri, Oct 30, 2020, 1:54 PM Niklas Hambüchen via Libraries < > libraries at haskell.org> wrote: > >> Hi Sean, >> >> On 29/10/2020 16:45, Sean Chalmers wrote: >> > I'm not sure what deets I need from you to transfer ownership? >> >> Usually you'd add your co-maintainers to the maintainers list under >> >> https://hackage.haskell.org/package/YOUR_PACKAGE_NAME/maintainers/ >> >> and give them push access to whatever version control you use for the >> package (e.g. Github). >> >> Cheers, >> Niklas >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Fri Oct 30 17:59:44 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 30 Oct 2020 17:59:44 +0000 Subject: Stepping away In-Reply-To: References: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> Message-ID: Davean's always good for a tip :) I can create a Waargonaut org and house this stuff if you're cool with it. I'll coordinate with Gwils and Tony. On Fri, Oct 30, 2020 at 1:57 PM, Sean Chalmers < sclhiannan at gmail.com > wrote: > > Agreed, orgs are good. We've a bit of logistics to sort for the repo but > apart from that it's all sorted now. Thanks for the tips. :) > > On Fri, 30 Oct 2020 at 17:56, David Feuer < david. feuer@ gmail. com ( > david.feuer at gmail.com ) > wrote: > > >> Ask Emily to create a GitHub "organization" and transfer ownership of the >> repository to that organization. Organizations are good because they can >> have multiple owners—redundancy is nice. Transferring the whole repository >> will also transfer all issues and pull requests. >> >> On Fri, Oct 30, 2020, 1:54 PM Niklas Hambüchen via Libraries < libraries@ haskell. >> org ( libraries at haskell.org ) > wrote: >> >> >>> Hi Sean, >>> >>> On 29/10/2020 16:45, Sean Chalmers wrote: >>> > I'm not sure what deets I need from you to transfer ownership? >>> >>> Usually you'd add your co-maintainers to the maintainers list under >>> >>> https:/ / hackage. haskell. org/ package/ YOUR_PACKAGE_NAME/ maintainers/ ( >>> https://hackage.haskell.org/package/YOUR_PACKAGE_NAME/maintainers/ ) >>> >>> and give them push access to whatever version control you use for the >>> package (e.g. Github). >>> >>> Cheers, >>> Niklas >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@ haskell. org ( Libraries at haskell.org ) >>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries ) >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sclhiannan at gmail.com Fri Oct 30 18:03:02 2020 From: sclhiannan at gmail.com (Sean Chalmers) Date: Fri, 30 Oct 2020 18:03:02 +0000 Subject: Stepping away In-Reply-To: References: <7425d5e8-8c40-3033-389a-c871f270c793@nh2.me> Message-ID: Totes mah goats! Have at it! On Fri, 30 Oct 2020 at 17:59, Emily Pillmore wrote: > Davean's always good for a tip :) > > I can create a Waargonaut org and house this stuff if you're cool with it. > I'll coordinate with Gwils and Tony. > > > On Fri, Oct 30, 2020 at 1:57 PM, Sean Chalmers > wrote: > >> Agreed, orgs are good. We've a bit of logistics to sort for the repo but >> apart from that it's all sorted now. Thanks for the tips. :) >> >> On Fri, 30 Oct 2020 at 17:56, David Feuer wrote: >> >>> Ask Emily to create a GitHub "organization" and transfer ownership of >>> the repository to that organization. Organizations are good because they >>> can have multiple owners—redundancy is nice. Transferring the whole >>> repository will also transfer all issues and pull requests. >>> >>> On Fri, Oct 30, 2020, 1:54 PM Niklas Hambüchen via Libraries < >>> libraries at haskell.org> wrote: >>> >>>> Hi Sean, >>>> >>>> On 29/10/2020 16:45, Sean Chalmers wrote: >>>> > I'm not sure what deets I need from you to transfer ownership? >>>> >>>> Usually you'd add your co-maintainers to the maintainers list under >>>> >>>> https://hackage.haskell.org/package/YOUR_PACKAGE_NAME/maintainers/ >>>> >>>> and give them push access to whatever version control you use for the >>>> package (e.g. Github). >>>> >>>> Cheers, >>>> Niklas >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: