From byorgey at gmail.com Sun Dec 1 03:21:27 2019 From: byorgey at gmail.com (Brent Yorgey) Date: Sat, 30 Nov 2019 21:21:27 -0600 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: References: <5242aefc-41ef-581c-6d3f-495a90ee2058@iki.fi> Message-ID: A few points: 1. The Bits instance for Integer essentially already behaves as if they are the 2-adic numbers. For example, if you use testBit you can discover that (-2 :: Integer) is treated as if it were an infinite sequence of 1's followed by a single 0. 2. However, because testBit takes an Int index, instances of Bits actually can't have an infinite number of 1 bits---at least not in practice---since you cannot observe anything past the (maxBound :: Int)th bit. 3. Currently, popCount on negative Integer values satisfies popCount (-x) = -(popCount x) which does not seem very well motivated and does not match the way negative values are presented via testBit. I am strongly -1 on moving popCount to FiniteBits. popCount on positive Integers is useful and well-defined. I am mildly +1 on Zemlya's proposal to change the behavior of popCount for negative Integer values, though I am not sure it is really worth the trouble. -Brent On Sat, Nov 30, 2019 at 10:10 AM Zemyla wrote: > popCount is a perfectly sensible method for Natural, and it could > theoretically become one for Integer as well if we say that, whenever > there's an infinite number of 1s and a finite number of 0s, then the result > is -(1 + count of 0s), as though it were maxBound :: Word bits in size and > merely converted to an Int (a sensible assumption, considering memory > limits). The results for types where there can be both infinite 0s and 1s > should still be an error. > > On Sat, Nov 30, 2019, 09:21 Oleg Grenrus wrote: > >> Although, popCount for Integer/Natural kind of makes sense, as they >> aren't infinite list of [Bit]s, but smarter structure. >> >> On 30.11.2019 17.17, Oleg Grenrus wrote: >> > I propose to change it to be member of FiniteBits >> > >> > I recall, there was a proposal to remove bitSize from Bits, so it's an >> > opportunity to introduce another small, yet breaking change at the >> > same time. >> > >> > Discussion time 2 week. >> > >> > - Oleg >> > >> > _______________________________________________ >> > 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 carter.schonwald at gmail.com Mon Dec 2 06:35:31 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 2 Dec 2019 01:35:31 -0500 Subject: Newtype wrapper for Float/Double with sensible Eq/Ord instances In-Reply-To: References: Message-ID: @chess, @Zemyla the ieee standard actually defines the following total order (i can send you the standard wrt the 2008 version if need be) negative nans, -inf, negative finite, 0's , positive finite, inf, positive nans (a very very different ordering than proposed here) @Zem, i would love some collab getting some RTS support into ghc for signaling nans, been a bit too busy to do all the work myself! so -1 on this proposal, and if you look back in the archives a few years ago you can see a pretty lengthy discussion around a bit more of a fleshed out proposal, though some of the end state work requires some more work on the ghc RTS the first piece needed to (subsequently implement the rest) appears in ghc 8.10, https://gitlab.haskell.org/ghc/ghc/commits/ghc-8.10.1-alpha1/compiler/cmm/CmmCallConv.hs https://gitlab.haskell.org/ghc/ghc/commit/42504f4a575395a35eec5c3fd7c9ef6e2b54e68e is the overall commit it makes SSE2 the only floating point flavor on intel platform (no more x87), which simplifies a lot of 1) determinism in rounding issues that by default would plague 32bit intel platforms, and also cleaned up a pretty crufty corner of the NCG that created a lot of other spurious complexity in improving floating point stuff On Sat, Nov 30, 2019 at 1:35 PM chessai . wrote: > I would argue there is no "sensible" implementation of Eq and Ord for > floating point. Better to have PartialEq [1] /PartialOrd [2]. > > [1]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html > > [2]: https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html > > On Sat, Nov 30, 2019, 11:21 AM Zemyla wrote: > >> There should be a newtype wrapper that wraps a RealFloat, keeps the >> Enum/Num/Fractional/so on instances, but gives it sensible ones for Eq and >> Ord, with the following order: >> >> NaN < -Inf < negative < -0 < +0 < positive < +Inf >> >> It may not belong in base, but if nothing else it definitely belongs in >> containers, because Set and Map depend critically on sensible instances of >> Ord. >> >> (Also, it should newtype derive Read and Show, so that people using them >> with GHCi see "fromList [(NaN, yadda), (-1.5, yadda), (2.7, blah), (+Inf, >> blah)]" instead of "fromList [(FloatOrd { unwrapFloat :: NaN }, yadda), >> ...".) >> _______________________________________________ >> 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 Mon Dec 2 06:37:00 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 2 Dec 2019 01:37:00 -0500 Subject: Newtype wrapper for Float/Double with sensible Eq/Ord instances In-Reply-To: References: Message-ID: big picture: improving floating point and friends is +1, and we can definitely have good quality newtypes, but lets make sure they're going to make everyone happy! (one interesting question, what about playing wiht newtypes that use reflection tricks to embed a relative error distance tolerance for equality?) On Mon, Dec 2, 2019 at 1:35 AM Carter Schonwald wrote: > @chess, @Zemyla > the ieee standard actually defines the following total order (i can send > you the standard wrt the 2008 version if need be) > negative nans, -inf, negative finite, 0's , positive finite, inf, > positive nans (a very very different ordering than proposed here) > > @Zem, i would love some collab getting some RTS support into ghc for > signaling nans, been a bit too busy to do all the work myself! > > so -1 on this proposal, and if you look back in the archives a few years > ago you can see a pretty lengthy discussion around a bit more of a fleshed > out proposal, > though some of the end state work requires some more work on the ghc RTS > > the first piece needed to (subsequently implement the rest) appears in ghc > 8.10, > https://gitlab.haskell.org/ghc/ghc/commits/ghc-8.10.1-alpha1/compiler/cmm/CmmCallConv.hs > > > https://gitlab.haskell.org/ghc/ghc/commit/42504f4a575395a35eec5c3fd7c9ef6e2b54e68e is > the overall commit > > it makes SSE2 the only floating point flavor on intel platform (no more > x87), which simplifies a lot of 1) determinism in rounding issues that by > default would plague 32bit intel platforms, and also cleaned up a pretty > crufty corner of the NCG that created a lot of other spurious complexity in > improving floating point stuff > > On Sat, Nov 30, 2019 at 1:35 PM chessai . wrote: > >> I would argue there is no "sensible" implementation of Eq and Ord for >> floating point. Better to have PartialEq [1] /PartialOrd [2]. >> >> [1]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html >> >> [2]: https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html >> >> On Sat, Nov 30, 2019, 11:21 AM Zemyla wrote: >> >>> There should be a newtype wrapper that wraps a RealFloat, keeps the >>> Enum/Num/Fractional/so on instances, but gives it sensible ones for Eq and >>> Ord, with the following order: >>> >>> NaN < -Inf < negative < -0 < +0 < positive < +Inf >>> >>> It may not belong in base, but if nothing else it definitely belongs in >>> containers, because Set and Map depend critically on sensible instances of >>> Ord. >>> >>> (Also, it should newtype derive Read and Show, so that people using them >>> with GHCi see "fromList [(NaN, yadda), (-1.5, yadda), (2.7, blah), (+Inf, >>> blah)]" instead of "fromList [(FloatOrd { unwrapFloat :: NaN }, yadda), >>> ...".) >>> _______________________________________________ >>> 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 oleg.grenrus at iki.fi Mon Dec 2 14:01:07 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 2 Dec 2019 16:01:07 +0200 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: References: <5242aefc-41ef-581c-6d3f-495a90ee2058@iki.fi> Message-ID: <3fc00c4a-e4c9-20b0-2ba2-9ac462438cc3@iki.fi> I'd refine the documentation of `Bits` class to say that it's a class for integral types with finite count of bits toggled, i.e. finite popCount. Than many things work out, except complementInteger is actually used. It's not a big change codewise: https://gitlab.haskell.org/ghc/ghc/merge_requests/2261 (GHC actually uses complementInteger for something itself). Without complement, Bits Natural would total instance, without partial methods. If complement for Integer is very important, then I'd propose to introduce classes to form diamond shape: -- instance can be defined for Integer class Bits b => Complement b where     complement :: b -> b -- instance can be defined for Natural class Bits b => PopCount b where     popCount :: b -> b class Complement b => FiniteBits b where     ... I think this is worth the trouble, this wart should been fixed when Natural was brought to base. And in fact, because of complement is in Bits, clearBit :: Natural -> Natural is broken in base-4.9.0.0 bundled with GHC-8.0: It went unnoticed, because there were default implementation using complement. If Haskell2020 will happen, it really should explain what the complement :: Natural -> Natural does otherwise. Haskell2010 just mentions that there is Bits Integer. For the report defense, popCount isn't in its Bits version. So, we made warts by both adding popCount to Bits and adding Natural Bits instance. Let's just fix them. - Oleg On 1.12.2019 5.21, Brent Yorgey wrote: > A few points: > > 1. The Bits instance for Integer essentially already behaves as if > they are the 2-adic numbers.  For example, if you use testBit you can > discover that (-2 :: Integer) is treated as if it were an infinite > sequence of 1's followed by a single 0. > 2. However, because testBit takes an Int index, instances of Bits > actually can't have an infinite number of 1 bits---at least not in > practice---since you cannot observe anything past the (maxBound :: > Int)th bit. > 3. Currently, popCount on negative Integer values satisfies popCount > (-x) = -(popCount x)  which does not seem very well motivated and does > not match the way negative values are presented via testBit. > > I am strongly -1 on moving popCount to FiniteBits. popCount on > positive Integers is useful and well-defined.  I am mildly +1 on > Zemlya's proposal to change the behavior of popCount for negative > Integer values, though I am not sure it is really worth the trouble. > > -Brent > > On Sat, Nov 30, 2019 at 10:10 AM Zemyla > wrote: > > popCount is a perfectly sensible method for Natural, and it could > theoretically become one for Integer as well if we say that, > whenever there's an infinite number of 1s and a finite number of > 0s, then the result is -(1 + count of 0s), as though it were > maxBound :: Word bits in size and merely converted to an Int (a > sensible assumption, considering memory limits). The results for > types where there can be both infinite 0s and 1s should still be > an error. > > On Sat, Nov 30, 2019, 09:21 Oleg Grenrus > wrote: > > Although, popCount for Integer/Natural kind of makes sense, as > they > aren't infinite list of [Bit]s, but smarter structure. > > On 30.11.2019 17.17, Oleg Grenrus wrote: > > I propose to change it to be member of FiniteBits > > > > I recall, there was a proposal to remove bitSize from Bits, > so it's an > > opportunity to introduce another small, yet breaking change > at the > > same time. > > > > Discussion time 2 week. > > > > - Oleg > > > > _______________________________________________ > > 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 ekmett at gmail.com Mon Dec 2 16:38:36 2019 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 2 Dec 2019 08:38:36 -0800 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: References: Message-ID: I'm pretty strongly -1 on moving popCount. Both the Natural and the slightly more... interesting... Integer implementations of that method have turned out to be quite useful in practice. -Edward On Sat, Nov 30, 2019 at 7:17 AM Oleg Grenrus wrote: > I propose to change it to be member of FiniteBits > > I recall, there was a proposal to remove bitSize from Bits, so it's an > opportunity to introduce another small, yet breaking change at the same > time. > > Discussion time 2 week. > > - Oleg > > _______________________________________________ > 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 ekmett at gmail.com Mon Dec 2 16:47:34 2019 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 2 Dec 2019 08:47:34 -0800 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: <3fc00c4a-e4c9-20b0-2ba2-9ac462438cc3@iki.fi> References: <5242aefc-41ef-581c-6d3f-495a90ee2058@iki.fi> <3fc00c4a-e4c9-20b0-2ba2-9ac462438cc3@iki.fi> Message-ID: I'm not averse to the idea of factoring out complementation into a separate class to make the Bits instance for Natural total. It strikes me as a laudable goal and it comes very close to encoding what Stone called a "Generalized Boolean Algebra" in the 30s, which hints to me that we might be onto the right abstraction here. Consider me a weak +1 there. -Edward On Mon, Dec 2, 2019 at 6:01 AM Oleg Grenrus wrote: > I'd refine the documentation of `Bits` class to say that it's a class for > integral types with finite count of bits toggled, i.e. finite popCount. > Than many things work out, except complementInteger is actually used. > > It's not a big change codewise: > https://gitlab.haskell.org/ghc/ghc/merge_requests/2261 (GHC actually uses > complementInteger for something itself). > > Without complement, Bits Natural would total instance, without partial > methods. If complement for Integer is very important, then I'd propose to > introduce classes to form diamond shape: > > -- instance can be defined for Integer > class Bits b => Complement b where > complement :: b -> b > > -- instance can be defined for Natural > class Bits b => PopCount b where > popCount :: b -> b > > class Complement b => FiniteBits b where > ... > > I think this is worth the trouble, this wart should been fixed when > Natural was brought to base. And in fact, because of complement is in Bits, > clearBit :: Natural -> Natural is broken in base-4.9.0.0 bundled with > GHC-8.0: It went unnoticed, because there were default implementation using > complement. If Haskell2020 will happen, it really should explain what the > complement :: Natural -> Natural does otherwise. Haskell2010 just mentions > that there is Bits Integer. For the report defense, popCount isn't in its > Bits version. > > So, we made warts by both adding popCount to Bits and adding Natural Bits > instance. Let's just fix them. > > - Oleg > On 1.12.2019 5.21, Brent Yorgey wrote: > > A few points: > > 1. The Bits instance for Integer essentially already behaves as if they > are the 2-adic numbers. For example, if you use testBit you can discover > that (-2 :: Integer) is treated as if it were an infinite sequence of 1's > followed by a single 0. > 2. However, because testBit takes an Int index, instances of Bits actually > can't have an infinite number of 1 bits---at least not in practice---since > you cannot observe anything past the (maxBound :: Int)th bit. > 3. Currently, popCount on negative Integer values satisfies popCount (-x) > = -(popCount x) which does not seem very well motivated and does not match > the way negative values are presented via testBit. > > I am strongly -1 on moving popCount to FiniteBits. popCount on positive > Integers is useful and well-defined. I am mildly +1 on Zemlya's proposal > to change the behavior of popCount for negative Integer values, though I am > not sure it is really worth the trouble. > > -Brent > > On Sat, Nov 30, 2019 at 10:10 AM Zemyla wrote: > >> popCount is a perfectly sensible method for Natural, and it could >> theoretically become one for Integer as well if we say that, whenever >> there's an infinite number of 1s and a finite number of 0s, then the result >> is -(1 + count of 0s), as though it were maxBound :: Word bits in size and >> merely converted to an Int (a sensible assumption, considering memory >> limits). The results for types where there can be both infinite 0s and 1s >> should still be an error. >> >> On Sat, Nov 30, 2019, 09:21 Oleg Grenrus wrote: >> >>> Although, popCount for Integer/Natural kind of makes sense, as they >>> aren't infinite list of [Bit]s, but smarter structure. >>> >>> On 30.11.2019 17.17, Oleg Grenrus wrote: >>> > I propose to change it to be member of FiniteBits >>> > >>> > I recall, there was a proposal to remove bitSize from Bits, so it's an >>> > opportunity to introduce another small, yet breaking change at the >>> > same time. >>> > >>> > Discussion time 2 week. >>> > >>> > - Oleg >>> > >>> > _______________________________________________ >>> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 3 04:01:51 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 2 Dec 2019 23:01:51 -0500 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: References: <5242aefc-41ef-581c-6d3f-495a90ee2058@iki.fi> <3fc00c4a-e4c9-20b0-2ba2-9ac462438cc3@iki.fi> Message-ID: I’d wanna first see how that factoring plays out, Strong -1 on dropping pop count instance Curious to poke at / think about the class refactoring. There’s definitely some ways this stuff could be evolved. Just need clarity on the cost vs benefits etc. On Mon, Dec 2, 2019 at 11:48 AM Edward Kmett wrote: > I'm not averse to the idea of factoring out complementation into a > separate class to make the Bits instance for Natural total. It strikes me > as a laudable goal and it comes very close to encoding what Stone called a > "Generalized Boolean Algebra" in the 30s, which hints to me that we might > be onto the right abstraction here. Consider me a weak +1 there. > > -Edward > > On Mon, Dec 2, 2019 at 6:01 AM Oleg Grenrus wrote: > >> I'd refine the documentation of `Bits` class to say that it's a class for >> integral types with finite count of bits toggled, i.e. finite popCount. >> Than many things work out, except complementInteger is actually used. >> >> It's not a big change codewise: >> https://gitlab.haskell.org/ghc/ghc/merge_requests/2261 (GHC actually >> uses complementInteger for something itself). >> >> Without complement, Bits Natural would total instance, without partial >> methods. If complement for Integer is very important, then I'd propose to >> introduce classes to form diamond shape: >> >> -- instance can be defined for Integer >> class Bits b => Complement b where >> complement :: b -> b >> >> -- instance can be defined for Natural >> class Bits b => PopCount b where >> popCount :: b -> b >> >> class Complement b => FiniteBits b where >> ... >> >> I think this is worth the trouble, this wart should been fixed when >> Natural was brought to base. And in fact, because of complement is in Bits, >> clearBit :: Natural -> Natural is broken in base-4.9.0.0 bundled with >> GHC-8.0: It went unnoticed, because there were default implementation using >> complement. If Haskell2020 will happen, it really should explain what the >> complement :: Natural -> Natural does otherwise. Haskell2010 just mentions >> that there is Bits Integer. For the report defense, popCount isn't in its >> Bits version. >> >> So, we made warts by both adding popCount to Bits and adding Natural Bits >> instance. Let's just fix them. >> >> - Oleg >> On 1.12.2019 5.21, Brent Yorgey wrote: >> >> A few points: >> >> 1. The Bits instance for Integer essentially already behaves as if they >> are the 2-adic numbers. For example, if you use testBit you can discover >> that (-2 :: Integer) is treated as if it were an infinite sequence of 1's >> followed by a single 0. >> 2. However, because testBit takes an Int index, instances of Bits >> actually can't have an infinite number of 1 bits---at least not in >> practice---since you cannot observe anything past the (maxBound :: Int)th >> bit. >> 3. Currently, popCount on negative Integer values satisfies popCount (-x) >> = -(popCount x) which does not seem very well motivated and does not match >> the way negative values are presented via testBit. >> >> I am strongly -1 on moving popCount to FiniteBits. popCount on positive >> Integers is useful and well-defined. I am mildly +1 on Zemlya's proposal >> to change the behavior of popCount for negative Integer values, though I am >> not sure it is really worth the trouble. >> >> -Brent >> >> On Sat, Nov 30, 2019 at 10:10 AM Zemyla wrote: >> >>> popCount is a perfectly sensible method for Natural, and it could >>> theoretically become one for Integer as well if we say that, whenever >>> there's an infinite number of 1s and a finite number of 0s, then the result >>> is -(1 + count of 0s), as though it were maxBound :: Word bits in size and >>> merely converted to an Int (a sensible assumption, considering memory >>> limits). The results for types where there can be both infinite 0s and 1s >>> should still be an error. >>> >>> On Sat, Nov 30, 2019, 09:21 Oleg Grenrus wrote: >>> >>>> Although, popCount for Integer/Natural kind of makes sense, as they >>>> aren't infinite list of [Bit]s, but smarter structure. >>>> >>>> On 30.11.2019 17.17, Oleg Grenrus wrote: >>>> > I propose to change it to be member of FiniteBits >>>> > >>>> > I recall, there was a proposal to remove bitSize from Bits, so it's >>>> an >>>> > opportunity to introduce another small, yet breaking change at the >>>> > same time. >>>> > >>>> > Discussion time 2 week. >>>> > >>>> > - Oleg >>>> > >>>> > _______________________________________________ >>>> > 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 >> > _______________________________________________ > 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 oleg.grenrus at iki.fi Tue Dec 3 18:45:14 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 3 Dec 2019 20:45:14 +0200 Subject: popCount is a method of Bits, not a FiniteBits In-Reply-To: References: <5242aefc-41ef-581c-6d3f-495a90ee2058@iki.fi> <3fc00c4a-e4c9-20b0-2ba2-9ac462438cc3@iki.fi> Message-ID: I made two MRs for GHC: - new class Bits b => Complement b in https://gitlab.haskell.org/ghc/ghc/merge_requests/2261 - or also class Bits b => PopCount b in https://gitlab.haskell.org/ghc/ghc/merge_requests/2270 The patches are quite direct, nothing surprising. GHC compiles fine itself, Few tests are failing: I'll fix them, if  we decide to go with either. - Oleg On 2.12.2019 18.47, Edward Kmett wrote: > I'm not averse to the idea of factoring out complementation into a > separate class to make the Bits instance for Natural total. It strikes > me as a laudable goal and it comes very close to encoding what Stone > called a "Generalized Boolean Algebra" in the 30s, which hints to me > that we might be onto the right abstraction here. Consider me a > weak +1 there. > > -Edward > > On Mon, Dec 2, 2019 at 6:01 AM Oleg Grenrus > wrote: > > I'd refine the documentation of `Bits` class to say that it's a > class for integral types with finite count of bits toggled, i.e. > finite popCount. > Than many things work out, except complementInteger is actually used. > > It's not a big change codewise: > https://gitlab.haskell.org/ghc/ghc/merge_requests/2261 (GHC > actually uses complementInteger for something itself). > > Without complement, Bits Natural would total instance, without > partial methods. If complement for Integer is very important, then > I'd propose to introduce classes to form diamond shape: > > -- instance can be defined for Integer > class Bits b => Complement b where >     complement :: b -> b > > -- instance can be defined for Natural > class Bits b => PopCount b where >     popCount :: b -> b > > class Complement b => FiniteBits b where >     ... > > I think this is worth the trouble, this wart should been fixed > when Natural was brought to base. And in fact, because of > complement is in Bits, clearBit :: Natural -> Natural is broken in > base-4.9.0.0 bundled with GHC-8.0: It went unnoticed, because > there were default implementation using complement. If Haskell2020 > will happen, it really should explain what the complement :: > Natural -> Natural does otherwise. Haskell2010 just mentions that > there is Bits Integer. For the report defense, popCount isn't in > its Bits version. > > So, we made warts by both adding popCount to Bits and adding > Natural Bits instance. Let's just fix them. > > - Oleg > > On 1.12.2019 5.21, Brent Yorgey wrote: >> A few points: >> >> 1. The Bits instance for Integer essentially already behaves as >> if they are the 2-adic numbers. For example, if you use testBit >> you can discover that (-2 :: Integer) is treated as if it were an >> infinite sequence of 1's followed by a single 0. >> 2. However, because testBit takes an Int index, instances of Bits >> actually can't have an infinite number of 1 bits---at least not >> in practice---since you cannot observe anything past the >> (maxBound :: Int)th bit. >> 3. Currently, popCount on negative Integer values satisfies >> popCount (-x) = -(popCount x)  which does not seem very well >> motivated and does not match the way negative values are >> presented via testBit. >> >> I am strongly -1 on moving popCount to FiniteBits. popCount on >> positive Integers is useful and well-defined.  I am mildly +1 on >> Zemlya's proposal to change the behavior of popCount for negative >> Integer values, though I am not sure it is really worth the trouble. >> >> -Brent >> >> On Sat, Nov 30, 2019 at 10:10 AM Zemyla > > wrote: >> >> popCount is a perfectly sensible method for Natural, and it >> could theoretically become one for Integer as well if we say >> that, whenever there's an infinite number of 1s and a finite >> number of 0s, then the result is -(1 + count of 0s), as >> though it were maxBound :: Word bits in size and merely >> converted to an Int (a sensible assumption, considering >> memory limits). The results for types where there can be both >> infinite 0s and 1s should still be an error. >> >> On Sat, Nov 30, 2019, 09:21 Oleg Grenrus > > wrote: >> >> Although, popCount for Integer/Natural kind of makes >> sense, as they >> aren't infinite list of [Bit]s, but smarter structure. >> >> On 30.11.2019 17.17, Oleg Grenrus wrote: >> > I propose to change it to be member of FiniteBits >> > >> > I recall, there was a proposal to remove bitSize from >> Bits, so it's an >> > opportunity to introduce another small, yet breaking >> change at the >> > same time. >> > >> > Discussion time 2 week. >> > >> > - Oleg >> > >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Dec 5 17:43:17 2019 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 5 Dec 2019 09:43:17 -0800 Subject: [core libraries] Adding Backwards to base, re-export from Control.Applicative In-Reply-To: References: Message-ID: I’m a strong +1 on moving Backwards and Reverse to base. This is basically free for everybody for a nice consistency win. I’m -1 on exporting them from Control.Applicative. That module is imported unqualified by a significant cross section of the Haskell ecosystem, so this just gratuitously introduces risk of name conflicts for little tangible benefit. In the presence of possible conflicts there I’d err on the side of the status quo over change for change’s sake. The only real precedent for doing so is that Control.Applicative also gratuitously exports Const, which is more historical accident than precedent to follow. -Edward > On Nov 27, 2019, at 1:36 PM, chessai . wrote: > >  > I think that makes sense. It wouldn't be disruptive, both changes are small but useful. > >> On Wed, Nov 27, 2019, 3:08 PM David Feuer wrote: >> If Backwards moves, then Reverse probably should too. >> >>> On Mon, Nov 25, 2019, 6:58 PM Baldur Blöndal wrote: >>> I'll CC Haskell Libraries >>> >>> þri., 12. nóv. 2019 kl. 22:14 skrifaði Ryan Scott : >>>> This discussion definitely belongs on the mailing list, yes. >>>> >>>> Ryan >>>> >>>>> On Tue, Nov 12, 2019 at 11:59 AM chessai . wrote: >>>>> I support this. +1 >>>>> >>>>> Should we copy in the libraries mailing list? >>>>> >>>>>> On Tue, Nov 12, 2019, 5:56 AM Baldur Blöndal wrote: >>>>>> Is it time to move Control.Applicative.Backwards module from transformers to base, and maybe re-export it from Control.Applicative. >>>>>> >>>>>> It's an interesting, important, simple property of Applicative that they can be run backwards. >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. >>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3DoZ%3D%2BKrM_k6TcZ89dvzvo0%2B288yDR8HL4bsDw%40mail.gmail.com. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. >>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg4NpTe%2B129ycFrOhTbcSHp_S9pX%3DdMh_DL%3Dg%40mail.gmail.com. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -- >> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAMgWh9tT%2BHJ1ZdGwzGuWmQXeQQGe6hWYWz3aEyhA13SMcu6OSw%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kKcuBmJOikkKfpHKnGu0hD%3DUXDYAMbs655A-7FtZbGzUQ%40mail.gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Fri Dec 13 03:11:13 2019 From: leon.p.smith at gmail.com (Leon Smith) Date: Thu, 12 Dec 2019 22:11:13 -0500 Subject: joinAtomicallyWithMask, and a potential resource leak in http-client Message-ID: I'm going to propose four new functions to add to the STM library, and would be interested in getting some feedback for this idea. The basic idea is that we implement these two functions, along with their WithUninterruptibleMask counterparts: {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} import Control.Monad(join) import Control.Concurrent.STM(STM, atomically) import Control.Exception(mask, mask_) joinAtomicallyWithMask :: STM ((forall a. (IO a -> IO a)) -> IO b) -> IO b joinAtomicallyWithMask transaction = mask $ \unmask -> do join . atomically $ do ioCont <- transaction return $ do ioCont unmask joinAtomicallyWithMask_ :: STM (IO b) -> IO b joinAtomicallyWithMask_ = mask_ . join . atomically However, the entire point of this endeavor is to implement these functions better than this. What we really want to do is to mask asynchronous exceptions in conjunction with an STM commit: a conservative implementation would upgrade the masking state shortly before we know if the transaction will commit or retry: if it retries, we restore the old masking state; if we commit, then we leave it alone. A perhaps more daring implementation would find a place immediately after commit before async exceptions could possibly appear, but this probably isn't necessary if the approach turns out to be too difficult/problematic. joinAtomicallyWithUninterruptibleMask actually allows us to express some programs that we couldn't before: will complete the STM transaction in an uninterruptible masking state, but we don't have to worry about blocking in the transaction because we won't have upgraded the masking state. I actually noticed this pattern twice recently: once in some code I was writing, and a second time within a week or two later, I noticed this would fix a potential resource leak in http-client, namely: https://github.com/snoyberg/http-client/blob/master/http-client/Data/KeyedPool.hs#L165 reap destroy var = loop where loop = do threadDelay (5 * 1000 * 1000) join $ atomically $ do m'' <- readTVar var case m'' of PoolClosed -> return (return ()) PoolOpen idleCount m | Map.null m -> retry | otherwise -> do (m', toDestroy) <- findStale idleCount m writeTVar var m' return $ do mask_ (mapM_ (ignoreExceptions . destroy) toDestroy) loop It looks like to me that we really want to ensure that we call "destroy" on every resource taken out of the pool, but it would appear that the mask_ is somewhat misplaced: while perhaps it removes the most likely places that an asynchronous exception could break that invariant, it looks like there's still a possibility that an asynchronous exception that happens after the transaction commits but before the call to `mask_`. And lastly, I know I independently came up with the join . atomically idiom, but I know I'm not the first nor the last to do so. It's an idiom that does deserve to be more widely appreciated, and this could be a way to do it. Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndospark320 at gmail.com Wed Dec 18 07:32:17 2019 From: ndospark320 at gmail.com (Dannyu NDos) Date: Wed, 18 Dec 2019 16:32:17 +0900 Subject: Update Read1 NonEmpty and Read1 Down Message-ID: It would be better if liftReadPrec is used instead of liftReadsPrec. instance Read1 NonEmpty where liftReadPrec rp rl = paren $ prec 5 $ do x <- rp Symbol ":|" <- lexP xs <- rl pure (x :| xs) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Wed Dec 18 08:47:47 2019 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Wed, 18 Dec 2019 17:47:47 +0900 Subject: haskell/bytestring stalled? Message-ID: I noticed that issues and PRs on bytestring repository[0] have received no feedback in past 6 months. Does anyone know what's going on? If I can help moving things along, I definitely would like to. [0] https://github.com/haskell/bytestring -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Dec 18 09:40:13 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 18 Dec 2019 10:40:13 +0100 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: Hello Fumiaki, Bytestring is a fundamental library which is used by almost everyone, so its goal is first and foremost to be stable and reliable; hence its maintenance is generally very conservative and slow-paced; it's better this way than to risk introducing regressions. But also, 6 months without visible feedback for a library that's generally considered mature isn't something to be alarmed about either. I for one cycle through the projects I maintain when time permits (usually on weekends) and try to reduce the context switches by working for several hours on a single project, eventually resulting in a new release. This batched mode of operation also means that it takes some time to complete an orbit around all projects and I don't consider this a bad thing; In fact, I don't subscribe to the release early and often poorly paradigm anymore after having exercised it myself as producer as well as experienced it as consumer for a couple decades and I've been burned too many time by careless rushed releases (both by myself as well as others). Maybe I'm just getting older and wiser. That being said, if you or others want to help out with projects I (co)maintain such as `bytestring`, please get into contact with me. There are things you can do to help with the review of PRs and other tasks that benefit from as many hands or eyes as possible and which would reduce the workload during the focused batch-phase when the careful dedicated release processes is initiated. -- Herbert On Wed, Dec 18, 2019 at 9:48 AM Fumiaki Kinoshita wrote: > I noticed that issues and PRs on bytestring repository[0] have received no > feedback in past 6 months. Does anyone know what's going on? If I can help > moving things along, I definitely would like to. > > [0] https://github.com/haskell/bytestring > _______________________________________________ > 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 simon.jakobi at googlemail.com Wed Dec 18 23:42:39 2019 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Thu, 19 Dec 2019 00:42:39 +0100 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: Thanks for bringing up this issue, Fumiaki! Your email prompted me to review a few PRs today: * [#155], which hadn't received a review since it it was opened a year and 9 months ago, promptly got new commits from its author, M Farkas-Dyck! :) * In [#151], which promises rather impressive performance improvements, the author Sergey Vinokurov reacted understandably disappointed to my requests for more benchmark results, after his PR had gone unacknowledged for 1 year and 10 months. I think #151 demonstrates how unresponsive maintenance hurts a project – contributors are disappointed by the lack of response and lose their motivation to finish their work. Potential contributors are discouraged when they see that existing PRs aren't getting merged. Moreover, I believe that when core libraries like bytestring get into such a sad state, it hurts the appearance of and users' confidence into the Haskell ecosystem as a whole. I don't blame Herbert or Duncan (CC'd) for not putting more work into bytestring – I'm thankful for all their amazing work for the Haskell ecosystem. But my impression is that both have far more (maintenance and other) responsibilities than available time for unpaid open source work. So I hope that they will allow others to help repair the current situation and get bytestring onto a more sustainable base. I would also like to ask Duncan, the official maintainer, whether he intends to become more active again in this project or whether he might be interested in passing the maintainer hat to someone with more available time for this project. I'm asking because there are at least two PRs that seem to be ready to go, except they're waiting for a review from him: * [#121] has been waiting for his review for 1 year and 10 months. * [#132] has been waiting for his review for at least 1 year and 11 months. Right now I believe it would be good to have a maintainer with the available time to shepherd some new contributors like Fumiaki or me. Since I admittedly don't trust Duncan and Herbert to have that time, I wonder whether someone else, for example from GHC HQ, could get the commit bits. I know that Ben Gamari (CC'd) has requested them for other reasons [1]. It's clear that there are several people interested in helping to maintain and improve bytestring – theindigamer15 (CC'd) offered his help this February in an email that never got an official response [2]. But as long as PRs are unlikely to get merged, there's no point in opening or reviewing one. Cheers, Simon [1] https://mail.haskell.org/pipermail/ghc-devops-group/2019-July/000322.html [2] https://mail.haskell.org/pipermail/haskell-cafe/2019-February/130705.html [#121] https://github.com/haskell/bytestring/pull/121 [#132] https://github.com/haskell/bytestring/pull/132 [#151] https://github.com/haskell/bytestring/pull/151 [#155] https://github.com/haskell/bytestring/pull/155 Am Mi., 18. Dez. 2019 um 10:40 Uhr schrieb Herbert Valerio Riedel : > > Hello Fumiaki, > > Bytestring is a fundamental library which is used by almost everyone, so its goal is first and foremost to be stable and reliable; hence its maintenance is generally very conservative and slow-paced; it's better this way than to risk introducing regressions. But also, 6 months without visible feedback for a library that's generally considered mature isn't something to be alarmed about either. I for one cycle through the projects I maintain when time permits (usually on weekends) and try to reduce the context switches by working for several hours on a single project, eventually resulting in a new release. This batched mode of operation also means that it takes some time to complete an orbit around all projects and I don't consider this a bad thing; In fact, I don't subscribe to the release early and often poorly paradigm anymore after having exercised it myself as producer as well as experienced it as consumer for a couple decades and I've been burned too many time by careless rushed releases (both by myself as well as others). Maybe I'm just getting older and wiser. > > That being said, if you or others want to help out with projects I (co)maintain such as `bytestring`, please get into contact with me. There are things you can do to help with the review of PRs and other tasks that benefit from as many hands or eyes as possible and which would reduce the workload during the focused batch-phase when the careful dedicated release processes is initiated. > > -- Herbert > > > On Wed, Dec 18, 2019 at 9:48 AM Fumiaki Kinoshita wrote: >> >> I noticed that issues and PRs on bytestring repository[0] have received no feedback in past 6 months. Does anyone know what's going on? If I can help moving things along, I definitely would like to. >> >> [0] https://github.com/haskell/bytestring >> _______________________________________________ >> 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 From hvriedel at gmail.com Thu Dec 19 07:19:54 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 19 Dec 2019 08:19:54 +0100 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: Hi Simon, On Thu, Dec 19, 2019 at 12:43 AM Simon Jakobi wrote: > Your email prompted me to review a few PRs today: Thank you, reviewing PRs is one of the things that definitely helps and what I was hoping for when I wrote > That being said, if you or others want to help out with projects I (co)maintain such as `bytestring`, please get into contact with me. There are things you can do to help with the review of PRs and other tasks that benefit from as many hands or eyes as possible and which would reduce the workload during the focused batch-phase when the careful dedicated release processes is initiated. But please; let's coordinate directly -- we've done so frequently via Hangout during your GSOC in the past -- than devolving into unhelpful public shade-throwing at how maintenance is currently performed; that is, if the goal is to actually help the project. -- Herbert From fumiexcel at gmail.com Thu Dec 19 08:25:32 2019 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Thu, 19 Dec 2019 17:25:32 +0900 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: Hello, I see some activity on GitHub; this strongly motivates me to start doing something concrete! Just looking at the situation, it definitely needs more reviewing - also I'm going to add tests and benchmarks to the pull requests. Given apparent absence of dcoutts, I'm curious we organise this in the future - currently a number of things are blocked on his response. If he's unable to spend time on it for some reason, I think that's much better to have Herbert or someone else as a primary maintainer. 2019年12月19日(木) 16:20 Herbert Valerio Riedel : > Hi Simon, > > On Thu, Dec 19, 2019 at 12:43 AM Simon Jakobi > wrote: > > Your email prompted me to review a few PRs today: > > Thank you, reviewing PRs is one of the things that definitely helps > and what I was hoping for when I wrote > > > That being said, if you or others want to help out with projects I > (co)maintain such as `bytestring`, please get into contact with me. There > are things you can do to help with the review of PRs and other tasks that > benefit from as many hands or eyes as possible and which would reduce the > workload during the focused batch-phase when the careful dedicated release > processes is initiated. > > But please; let's coordinate directly -- we've done so frequently via > Hangout during your GSOC in the past -- than devolving into unhelpful > public shade-throwing at how maintenance is currently performed; that > is, if the goal is to actually help the project. > > -- Herbert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Dec 19 14:49:06 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 19 Dec 2019 09:49:06 -0500 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: I’m reasonably comfortable saying duncan should not be in the loop on this stuff. He hasn’t been active or communicating accessibly in a while. And that’s fine. Peoples lives are complicated and busy. Let’s move forward. Let’s move forward and just make sure we do a very meticulous and thoughtful execution of progressing bytestring. (On a personal level, some of my fall oss plans fell on the wayside after my 12 yr old niece got very sick in September). On Thu, Dec 19, 2019 at 3:25 AM Fumiaki Kinoshita wrote: > Hello, > > I see some activity on GitHub; this strongly motivates me to start doing > something concrete! > Just looking at the situation, it definitely needs more reviewing - also > I'm going to add tests and benchmarks to the pull requests. > > Given apparent absence of dcoutts, I'm curious we organise this in the > future - currently a number of things are blocked on his response. If he's > unable to spend time on it for some reason, I think that's much better to > have Herbert or someone else as a primary maintainer. > > 2019年12月19日(木) 16:20 Herbert Valerio Riedel : > >> Hi Simon, >> >> On Thu, Dec 19, 2019 at 12:43 AM Simon Jakobi >> wrote: >> > Your email prompted me to review a few PRs today: >> >> Thank you, reviewing PRs is one of the things that definitely helps >> and what I was hoping for when I wrote >> >> > That being said, if you or others want to help out with projects I >> (co)maintain such as `bytestring`, please get into contact with me. There >> are things you can do to help with the review of PRs and other tasks that >> benefit from as many hands or eyes as possible and which would reduce the >> workload during the focused batch-phase when the careful dedicated release >> processes is initiated. >> >> But please; let's coordinate directly -- we've done so frequently via >> Hangout during your GSOC in the past -- than devolving into unhelpful >> public shade-throwing at how maintenance is currently performed; that >> is, if the goal is to actually help the project. >> >> -- Herbert >> > _______________________________________________ > 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 simon.jakobi at googlemail.com Thu Dec 19 16:20:28 2019 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Thu, 19 Dec 2019 17:20:28 +0100 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: Hi Herbert, I apologize for the overly harsh and accusatory tone in my last email. After looking through the existing PRs and issues, I was admittedly somewhat disappointed over the current situation with bytestring issues and PRs, but I shouldn't have expressed my feelings in this way. Also, thanks a lot for responding so quickly today to my many comments on issues and PRs. To be clear, I'm not interested in putting blame on you or Duncan or anyone else. I do however strongly believe that bytestring needs a more responsive maintainer: 1. Contributors IMO deserve to get a response within weeks or ideally days. 2. bytestring users (and that transitively includes all GHC users) could benefit massively if some of the current PRs were finally merged. For example in [#175], Sylvain Henry reports improvements of **11%** for some compilation tasks when he used the PR to build GHC. And I admittedly don't want to ask you, Herbert, to lead the effort of clearing up the maintenance backlog in bytestring. Of course, _any_ Haskell project you're involved in benefits from your massive experience! However, I feel that since your involvement is so crucial in so many other essential projects in the Haskell ecosystem, if you would shift your focus towards bytestring, these other projects would suffer! I also believe that projects like cabal or Hackage need your domain knowledge more dearly than bytestring does. So to ask you to allocate more time to bytestring, would feel a bit like a zero-sum game, or possibly a negative-sum game. A second, more personal reason, why I would prefer to see a different maintainer for bytestring, is your preference for coordinating things in private communication. The many PRs and issues in the bytestring project, and this email thread demonstrate that there are a lot of people who would like to be involved in improving bytestring. Private coordination would exclude most of them, and make it more difficult to make use of all the help that this project currently needs. I understand that your preference for private communication is related to your experiences with previous discussions over Haskell projects, and I am sorry that it has come so far, but I believe that a more open and transparent style of communication is more healthy. So, while I'm very grateful for your work on bytestring, and while I hope that you stay involved in the project, I hope that that someone else can take over official maintainer duties. Now I am not sure who could take on that job. Clearly we need someone whom Duncan trusts. That's why I wonder whether someone involved in the performance work on GHC could help. Ultimately I don't think that their time involvement would need to be very high – good judgment and responsiveness seem more important to me. I'm CC'ing the ghc-devs list, hoping that someone with the right experience and availability would come forward. Thanks, Simon [#175] https://github.com/haskell/bytestring/pull/175#issuecomment-567233984 From david.feuer at gmail.com Thu Dec 19 16:35:47 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 19 Dec 2019 11:35:47 -0500 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: One thing that would help a bit, I imagine, would be to improve the treatment of unsafeDupablePerformIO in GHC so that bytestring can drop the fragile accursedUnutterablePerformIO without significant performance loss. There's been some discussion about how to do so, but no resolution has been reached. On Thu, Dec 19, 2019 at 11:21 AM Simon Jakobi via Libraries wrote: > > Hi Herbert, > > I apologize for the overly harsh and accusatory tone in my last email. > After looking through the existing PRs and issues, I was admittedly > somewhat disappointed over the current situation with bytestring > issues and PRs, but I shouldn't have expressed my feelings in this > way. > > Also, thanks a lot for responding so quickly today to my many comments > on issues and PRs. > > To be clear, I'm not interested in putting blame on you or Duncan or > anyone else. I do however strongly believe that bytestring needs a > more responsive maintainer: > > 1. Contributors IMO deserve to get a response within weeks or ideally days. > > 2. bytestring users (and that transitively includes all GHC users) > could benefit massively if some of the current PRs were finally > merged. For example in [#175], Sylvain Henry reports improvements of > **11%** for some compilation tasks when he used the PR to build GHC. > > And I admittedly don't want to ask you, Herbert, to lead the effort of > clearing up the maintenance backlog in bytestring. Of course, _any_ > Haskell project you're involved in benefits from your massive > experience! However, I feel that since your involvement is so crucial > in so many other essential projects in the Haskell ecosystem, if you > would shift your focus towards bytestring, these other projects would > suffer! I also believe that projects like cabal or Hackage need your > domain knowledge more dearly than bytestring does. So to ask you to > allocate more time to bytestring, would feel a bit like a zero-sum > game, or possibly a negative-sum game. > > A second, more personal reason, why I would prefer to see a different > maintainer for bytestring, is your preference for coordinating things > in private communication. The many PRs and issues in the bytestring > project, and this email thread demonstrate that there are a lot of > people who would like to be involved in improving bytestring. Private > coordination would exclude most of them, and make it more difficult to > make use of all the help that this project currently needs. I > understand that your preference for private communication is related > to your experiences with previous discussions over Haskell projects, > and I am sorry that it has come so far, but I believe that a more open > and transparent style of communication is more healthy. > > So, while I'm very grateful for your work on bytestring, and while I > hope that you stay involved in the project, I hope that that someone > else can take over official maintainer duties. > > Now I am not sure who could take on that job. Clearly we need someone > whom Duncan trusts. That's why I wonder whether someone involved in > the performance work on GHC could help. Ultimately I don't think that > their time involvement would need to be very high – good judgment and > responsiveness seem more important to me. I'm CC'ing the ghc-devs > list, hoping that someone with the right experience and availability > would come forward. > > Thanks, > Simon > > [#175] https://github.com/haskell/bytestring/pull/175#issuecomment-567233984 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From simon.jakobi at googlemail.com Thu Dec 19 16:58:17 2019 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Thu, 19 Dec 2019 17:58:17 +0100 Subject: haskell/bytestring stalled? In-Reply-To: References: Message-ID: I'm also CC'ing the core libraries committee – sorry for not realizing earlier that they would be interested in this discussion! Am Do., 19. Dez. 2019 um 17:20 Uhr schrieb Simon Jakobi : > > Hi Herbert, > > I apologize for the overly harsh and accusatory tone in my last email. > After looking through the existing PRs and issues, I was admittedly > somewhat disappointed over the current situation with bytestring > issues and PRs, but I shouldn't have expressed my feelings in this > way. > > Also, thanks a lot for responding so quickly today to my many comments > on issues and PRs. > > To be clear, I'm not interested in putting blame on you or Duncan or > anyone else. I do however strongly believe that bytestring needs a > more responsive maintainer: > > 1. Contributors IMO deserve to get a response within weeks or ideally days. > > 2. bytestring users (and that transitively includes all GHC users) > could benefit massively if some of the current PRs were finally > merged. For example in [#175], Sylvain Henry reports improvements of > **11%** for some compilation tasks when he used the PR to build GHC. > > And I admittedly don't want to ask you, Herbert, to lead the effort of > clearing up the maintenance backlog in bytestring. Of course, _any_ > Haskell project you're involved in benefits from your massive > experience! However, I feel that since your involvement is so crucial > in so many other essential projects in the Haskell ecosystem, if you > would shift your focus towards bytestring, these other projects would > suffer! I also believe that projects like cabal or Hackage need your > domain knowledge more dearly than bytestring does. So to ask you to > allocate more time to bytestring, would feel a bit like a zero-sum > game, or possibly a negative-sum game. > > A second, more personal reason, why I would prefer to see a different > maintainer for bytestring, is your preference for coordinating things > in private communication. The many PRs and issues in the bytestring > project, and this email thread demonstrate that there are a lot of > people who would like to be involved in improving bytestring. Private > coordination would exclude most of them, and make it more difficult to > make use of all the help that this project currently needs. I > understand that your preference for private communication is related > to your experiences with previous discussions over Haskell projects, > and I am sorry that it has come so far, but I believe that a more open > and transparent style of communication is more healthy. > > So, while I'm very grateful for your work on bytestring, and while I > hope that you stay involved in the project, I hope that that someone > else can take over official maintainer duties. > > Now I am not sure who could take on that job. Clearly we need someone > whom Duncan trusts. That's why I wonder whether someone involved in > the performance work on GHC could help. Ultimately I don't think that > their time involvement would need to be very high – good judgment and > responsiveness seem more important to me. I'm CC'ing the ghc-devs > list, hoping that someone with the right experience and availability > would come forward. > > Thanks, > Simon > > [#175] https://github.com/haskell/bytestring/pull/175#issuecomment-567233984 From vliepelt at futurefinance.com Sun Dec 22 11:44:58 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Sun, 22 Dec 2019 13:44:58 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` Message-ID: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Has there been any discussion about adding WARNING pragmas to `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? I suppose this hasn't been done yet to avoid breaking existing code which makes "legitimate" use of those helpers? From chessai1996 at gmail.com Sun Dec 22 11:50:21 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 22 Dec 2019 06:50:21 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: Right, it's been discussed before IIRC, and i know I've certainly given it passing thoughts. I think this isn't worth it because of breakage. Many people use -Wall -Werror, so I see this as a no-go. Thanka On Sun, Dec 22, 2019, 6:45 AM Vilem Liepelt wrote: > Has there been any discussion about adding WARNING pragmas to > `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? > > I suppose this hasn't been done yet to avoid breaking existing code which > makes "legitimate" use of those helpers? > _______________________________________________ > 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 zemyla at gmail.com Sun Dec 22 12:15:08 2019 From: zemyla at gmail.com (Zemyla) Date: Sun, 22 Dec 2019 06:15:08 -0600 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: The most common legitimate usage for undefined I have is strictness: func x y | x `seq` False = undefined func x y = ... There's nothing else that would go there, and when it's compiled, the reference to undefined disappears. On Sun, Dec 22, 2019, 05:50 chessai . wrote: > Right, it's been discussed before IIRC, and i know I've certainly given it > passing thoughts. I think this isn't worth it because of breakage. Many > people use -Wall -Werror, so I see this as a no-go. > > Thanka > > On Sun, Dec 22, 2019, 6:45 AM Vilem Liepelt > wrote: > >> Has there been any discussion about adding WARNING pragmas to >> `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? >> >> I suppose this hasn't been done yet to avoid breaking existing code which >> makes "legitimate" use of those helpers? >> _______________________________________________ >> 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 fa-ml at ariis.it Sun Dec 22 12:26:58 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 22 Dec 2019 13:26:58 +0100 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: <20191222122658.GA6372@x60s.casa> On Sun, Dec 22, 2019 at 01:44:58PM +0200, Vilem Liepelt wrote: > Has there been any discussion about adding WARNING pragmas to `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? > > I suppose this hasn't been done yet to avoid breaking existing code which makes "legitimate" use of those helpers? `undefined` is useful when you want to check types in, e.g. ghcid, without writing a function in full. With -Wall on, that Warning could become annoying fast. From andreas.abel at ifi.lmu.de Mon Dec 23 11:36:51 2019 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Mon, 23 Dec 2019 12:36:51 +0100 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: I am missing some context of this discussion, but if this is the question of whether using `undefined` and `error` can be legitimate, yes they can. If you know your invariants, you might want to write fromMaybe undefined $ lookup key map or Map.findWithDefault undefined key map knowing you put the key into the map and the lookup cannot fail. On 2019-12-22 13:15, Zemyla wrote: > The most common legitimate usage for undefined I have is strictness: > > func x y | x `seq` False = undefined > func x y = ... > > There's nothing else that would go there, and when it's compiled, the > reference to undefined disappears. > > On Sun, Dec 22, 2019, 05:50 chessai . > wrote: > > Right, it's been discussed before IIRC, and i know I've certainly > given it passing thoughts. I think this isn't worth it because of > breakage. Many people use -Wall -Werror, so I see this as a no-go. > > Thanka > > On Sun, Dec 22, 2019, 6:45 AM Vilem Liepelt > > wrote: > > Has there been any discussion about adding WARNING pragmas to > `Prelude.undefined` and `Prelude.error`, as done in some custom > preludes? > > I suppose this hasn't been done yet to avoid breaking existing > code which makes "legitimate" use of those helpers? > _______________________________________________ > 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 > From vliepelt at futurefinance.com Mon Dec 23 11:55:39 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 13:55:39 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: I agree that `error`/`undefined` can be legitimate; however often this legitimacy rests on invariants that aren't necessary stable under change-types-and-fix-errors-until-things-type-check style refactoring! So after refactoring I'd like to switch on my `error`/`undefined` warnings temporarily. > On 23 Dec 2019, at 13:36, Andreas Abel wrote: > > I am missing some context of this discussion, but if this is the question of whether using `undefined` and `error` can be legitimate, yes they can. If you know your invariants, you might want to write > > fromMaybe undefined $ lookup key map > > or > > Map.findWithDefault undefined key map > > knowing you put the key into the map and the lookup cannot fail. > > On 2019-12-22 13:15, Zemyla wrote: >> The most common legitimate usage for undefined I have is strictness: >> func x y | x `seq` False = undefined >> func x y = ... >> There's nothing else that would go there, and when it's compiled, the reference to undefined disappears. >> On Sun, Dec 22, 2019, 05:50 chessai . > wrote: >> Right, it's been discussed before IIRC, and i know I've certainly >> given it passing thoughts. I think this isn't worth it because of >> breakage. Many people use -Wall -Werror, so I see this as a no-go. >> Thanka >> On Sun, Dec 22, 2019, 6:45 AM Vilem Liepelt >> > wrote: >> Has there been any discussion about adding WARNING pragmas to >> `Prelude.undefined` and `Prelude.error`, as done in some custom >> preludes? >> I suppose this hasn't been done yet to avoid breaking existing >> code which makes "legitimate" use of those helpers? >> _______________________________________________ >> 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 From lemming at henning-thielemann.de Mon Dec 23 12:02:56 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 23 Dec 2019 13:02:56 +0100 (CET) Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: On Mon, 23 Dec 2019, Vilem Liepelt wrote: > I agree that `error`/`undefined` can be legitimate; however often this > legitimacy rests on invariants that aren't necessary stable under > change-types-and-fix-errors-until-things-type-check style refactoring! > So after refactoring I'd like to switch on my `error`/`undefined` > warnings temporarily. I assume a TotalHaskell pragma was proposed in the past. Would this help? From vliepelt at futurefinance.com Mon Dec 23 13:12:26 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 15:12:26 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: > I assume a TotalHaskell pragma was proposed in the past. Would this help? Yes, in fact I think this is even better. Does "total" refer to exhaustive pattern matching and absence of (possible) exceptions? We might want to have such a pragma on a function-by-function basis as well as whole-module. My company has committed to letting me work on GHC a couple of days each month, so I'd be up to work on this, although I'd need someone to hold my hand as I haven't done this before. From rae at richarde.dev Mon Dec 23 15:44:06 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 23 Dec 2019 10:44:06 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> I have not seen a serious proposal for TotalHaskell before. It would be a great thing to have, but my guess is that at least two PhD students would have to be sacrificed to the cause. There are *many* ways that Haskell is a non-total language. Here are a few: - general recursion (including definitions like loop = loop) - well-founded recursion (where the recursive calls are on structurally smaller arguments) is ok, though - but not on infinite data - well-guarded corecursion (like `ones = 1 : ones`) is also ok - recursive type-class dictionaries allows (I think) unbounded recursion - exceptions - incomplete pattern matches - unless GADT restrictions say that the match is actually total - incomplete uni-pattern matches - unless GADT restrictions say that the match is actually total - partial record selectors - non-strictly-positive datatypes - Typeable allows you to simulate non-strictly-positive datatypes (see Sec. 7 of https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs) - Girard's paradox (because we have Type :: Type), though it is not known whether this is encodable in Haskell. See https://link.springer.com/chapter/10.1007/BFb0014058 - -fdefer-type-errors Some of these are easy enough to stamp out, but others may be harder. And I'm sure I'm missing some cases. I am *not* trying to say we shouldn't do anything in this direction -- far from it. However, one should proceed in this direction with eyes open. Richard > On Dec 23, 2019, at 8:12 AM, Vilem Liepelt wrote: > > >> I assume a TotalHaskell pragma was proposed in the past. Would this help? > > Yes, in fact I think this is even better. Does "total" refer to exhaustive pattern matching and absence of (possible) exceptions? > > We might want to have such a pragma on a function-by-function basis as well as whole-module. > > My company has committed to letting me work on GHC a couple of days each month, so I'd be up to work on this, although I'd need someone to hold my hand as I haven't done this before. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From vliepelt at futurefinance.com Mon Dec 23 16:04:23 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 18:04:23 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> Message-ID: <32DD0710-73CA-404A-A29C-BD41CEBF9DA0@futurefinance.com> I agree with your assessment, Richard, but my (possibly flawed) understanding is that in the Haskell community "totality" does not have the same meaning as in mathematics/PLT—Haskellers use "total" for the property "doesn't throw non-exhaustive pattern match errors" or perhaps "doesn't throw any exceptions at all" vs "terminating" for the property "doesn't loop infinitely". [citation needed] Hence I understood Henning's proposal to refer to the notion of "exception-free". This would already be a very useful property and I suspect would be easier to solve. Yes, complete pattern matches are undecidable in the presence of GADTs, but can't we simply build on GHC's existing heuristics? Would this really be a pragma or would it be a language /restriction/ (heh)? Regarding nontermination, I would be grateful if Haskell at least had an option for explicit let-rec... > On 23 Dec 2019, at 17:44, Richard Eisenberg wrote: > > GADT restrictions say that the match is actually total > - incomplete uni-pattern matches > - unless GADT restrictions say that the match is actually total > - partial record selectors > - non-strictly-positive datatypes > - Typeable allows you to simulate non-strictly-positive datatypes (see Sec. 7 of https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs ) > - Girard's paradox (because we have Type :: Type), though it is not known whether this is encodable in Haskell. See https://link.springer.com/chapter/10.1007/BFb0014058 > - -fdefer-type-errors -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhelta.diaz at gmail.com Mon Dec 23 16:10:47 2019 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Mon, 23 Dec 2019 17:10:47 +0100 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: Some warnings are not included in -Wall (for instance -Wincomplete-uni-patterns). New warning flags can be added without breaking any code. Best regards, Daniel Am So., 22. Dez. 2019 um 12:50 Uhr schrieb chessai . : > Right, it's been discussed before IIRC, and i know I've certainly given it > passing thoughts. I think this isn't worth it because of breakage. Many > people use -Wall -Werror, so I see this as a no-go. > > Thanka > > On Sun, Dec 22, 2019, 6:45 AM Vilem Liepelt > wrote: > >> Has there been any discussion about adding WARNING pragmas to >> `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? >> >> I suppose this hasn't been done yet to avoid breaking existing code which >> makes "legitimate" use of those helpers? >> _______________________________________________ >> 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 vliepelt at futurefinance.com Mon Dec 23 16:30:29 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 18:30:29 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: > On 22 Dec 2019, at 14:15, Zemyla wrote: > > The most common legitimate usage for undefined I have is strictness: > > func x y | x `seq` False = undefined > func x y = ... > > There's nothing else that would go there, and when it's compiled, the reference to undefined disappears. Is this (better than | different from) using BangPatterns? From vliepelt at futurefinance.com Mon Dec 23 16:33:39 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 18:33:39 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: <459B9867-56C4-408C-B9B3-0F1AC84A52A6@futurefinance.com> > On 23 Dec 2019, at 18:10, Daniel Díaz Casanueva wrote: > > Some warnings are not included in -Wall (for instance -Wincomplete-uni-patterns). New warning flags can be added without breaking any code. Agreed, Daniel, but if we added a warning/deprecation pragma to the library (which is what I had asked about), then this would get triggered by -Wdeprecations which is part of -Wall. I'm not sure adding a flag specifically for usages of `error`/`undefined` makes much sense. E.g. what if I bind those names to genuine values? From dhelta.diaz at gmail.com Mon Dec 23 19:48:48 2019 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Mon, 23 Dec 2019 20:48:48 +0100 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <459B9867-56C4-408C-B9B3-0F1AC84A52A6@futurefinance.com> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <459B9867-56C4-408C-B9B3-0F1AC84A52A6@futurefinance.com> Message-ID: Oh, I see. Sorry. I totally misunderstood the proposal. I should have read more carefully. I think undefined and error are useful functions to have, so why adding WARNING to them? For example, you can fold an infinite structure `xs` with `foldr f undefined xs` (for some proper `f`) without needing to define or look for an alternative to `Data.Foldable.foldr`. Am Mo., 23. Dez. 2019 um 17:33 Uhr schrieb Vilem Liepelt < vliepelt at futurefinance.com>: > > > On 23 Dec 2019, at 18:10, Daniel Díaz Casanueva > wrote: > > > > Some warnings are not included in -Wall (for instance > -Wincomplete-uni-patterns). New warning flags can be added without breaking > any code. > > Agreed, Daniel, but if we added a warning/deprecation pragma to the > library (which is what I had asked about), then this would get triggered by > -Wdeprecations which is part of -Wall. I'm not sure adding a flag > specifically for usages of `error`/`undefined` makes much sense. E.g. what > if I bind those names to genuine values? -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Dec 23 20:25:27 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 23 Dec 2019 15:25:27 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> Message-ID: i agree with richard here: i'd even say it more strongly: totality is a global property, any "local only " mechanism will backfire on some valid total code. worst of all: any theorem prover extracted code will be rejected :) (well, at least the sort coq/agda extract to, isabelle/hol code tends to have less unsafe coerce party time, though still would likely fail any "local" totally rules of thumb). On Mon, Dec 23, 2019 at 10:48 AM Richard Eisenberg wrote: > I have not seen a serious proposal for TotalHaskell before. It would be a > great thing to have, but my guess is that at least two PhD students would > have to be sacrificed to the cause. There are *many* ways that Haskell is a > non-total language. > > Here are a few: > > - general recursion (including definitions like loop = loop) > - well-founded recursion (where the recursive calls are on structurally > smaller arguments) is ok, though > - but not on infinite data > - well-guarded corecursion (like `ones = 1 : ones`) is also ok > - recursive type-class dictionaries allows (I think) unbounded recursion > - exceptions > - incomplete pattern matches > - unless GADT restrictions say that the match is actually total > - incomplete uni-pattern matches > - unless GADT restrictions say that the match is actually total > - partial record selectors > - non-strictly-positive datatypes > - Typeable allows you to simulate non-strictly-positive datatypes (see > Sec. 7 of > https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs > ) > - Girard's paradox (because we have Type :: Type), though it is not known > whether this is encodable in Haskell. See > https://link.springer.com/chapter/10.1007/BFb0014058 > - -fdefer-type-errors > > Some of these are easy enough to stamp out, but others may be harder. And > I'm sure I'm missing some cases. I am *not* trying to say we shouldn't do > anything in this direction -- far from it. However, one should proceed in > this direction with eyes open. > > Richard > > > On Dec 23, 2019, at 8:12 AM, Vilem Liepelt > wrote: > > > > > >> I assume a TotalHaskell pragma was proposed in the past. Would this > help? > > > > Yes, in fact I think this is even better. Does "total" refer to > exhaustive pattern matching and absence of (possible) exceptions? > > > > We might want to have such a pragma on a function-by-function basis as > well as whole-module. > > > > My company has committed to letting me work on GHC a couple of days each > month, so I'd be up to work on this, although I'd need someone to hold my > hand as I haven't done this before. > > _______________________________________________ > > 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 tikhon at jelv.is Mon Dec 23 20:51:56 2019 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 23 Dec 2019 12:51:56 -0800 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> Message-ID: In our codebase at work, undefined had a warning and we have a value called unreachable for cases where it makes sense semantically. We use undefined during development and the warning acts as both a safety net and a list of todos to fix before the code is ready to merge. On Mon, Dec 23, 2019, 12:26 Carter Schonwald wrote: > i agree with richard here: > > i'd even say it more strongly: > totality is a global property, any "local only " mechanism will backfire > on some valid total code. > > worst of all: any theorem prover extracted code will be rejected :) > (well, at least the sort coq/agda extract to, isabelle/hol code tends to > have less unsafe coerce party time, though still would likely fail any > "local" totally rules of thumb). > > On Mon, Dec 23, 2019 at 10:48 AM Richard Eisenberg > wrote: > >> I have not seen a serious proposal for TotalHaskell before. It would be a >> great thing to have, but my guess is that at least two PhD students would >> have to be sacrificed to the cause. There are *many* ways that Haskell is a >> non-total language. >> >> Here are a few: >> >> - general recursion (including definitions like loop = loop) >> - well-founded recursion (where the recursive calls are on structurally >> smaller arguments) is ok, though >> - but not on infinite data >> - well-guarded corecursion (like `ones = 1 : ones`) is also ok >> - recursive type-class dictionaries allows (I think) unbounded recursion >> - exceptions >> - incomplete pattern matches >> - unless GADT restrictions say that the match is actually total >> - incomplete uni-pattern matches >> - unless GADT restrictions say that the match is actually total >> - partial record selectors >> - non-strictly-positive datatypes >> - Typeable allows you to simulate non-strictly-positive datatypes (see >> Sec. 7 of >> https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs >> ) >> - Girard's paradox (because we have Type :: Type), though it is not known >> whether this is encodable in Haskell. See >> https://link.springer.com/chapter/10.1007/BFb0014058 >> - -fdefer-type-errors >> >> Some of these are easy enough to stamp out, but others may be harder. And >> I'm sure I'm missing some cases. I am *not* trying to say we shouldn't do >> anything in this direction -- far from it. However, one should proceed in >> this direction with eyes open. >> >> Richard >> >> > On Dec 23, 2019, at 8:12 AM, Vilem Liepelt >> wrote: >> > >> > >> >> I assume a TotalHaskell pragma was proposed in the past. Would this >> help? >> > >> > Yes, in fact I think this is even better. Does "total" refer to >> exhaustive pattern matching and absence of (possible) exceptions? >> > >> > We might want to have such a pragma on a function-by-function basis as >> well as whole-module. >> > >> > My company has committed to letting me work on GHC a couple of days >> each month, so I'd be up to work on this, although I'd need someone to hold >> my hand as I haven't done this before. >> > _______________________________________________ >> > 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 vliepelt at futurefinance.com Mon Dec 23 21:05:00 2019 From: vliepelt at futurefinance.com (Vilem Liepelt) Date: Mon, 23 Dec 2019 23:05:00 +0200 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <459B9867-56C4-408C-B9B3-0F1AC84A52A6@futurefinance.com> Message-ID: <78A748FC-4095-4EE1-9A84-ADFE9D6B0ECB@futurefinance.com> > On 23 Dec 2019, at 21:48, Daniel Díaz Casanueva wrote: > > Oh, I see. Sorry. I totally misunderstood the proposal. I should have read more carefully. > > I think undefined and error are useful functions to have, so why adding WARNING to them? For example, you can fold an infinite structure `xs` with `foldr f undefined xs` (for some proper `f`) without needing to define or look for an alternative to `Data.Foldable.foldr`. Yes, as long as the structure really is infinite. However the types don't guarantee or even suggest this, so this can easily blow up after a refactor that doesn't take this unwritten rule into consideration. If `undefined` came with a WARNING, then that might encourage you to try to express your solution with a proper coinductive data structure. :) From vamchale at gmail.com Tue Dec 24 16:53:33 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Tue, 24 Dec 2019 16:53:33 +0000 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> Message-ID: <90f22f36-0bcc-0876-b21a-64fd3af9c858@gmail.com> You can use hlint to ban a function (such as undefined) in a particular codebase. I use it to avoid releasing packages without a real error message. Cheers, Vanessa On 12/23/19 8:51 PM, Tikhon Jelvis wrote: > In our codebase at work, undefined had a warning and we have a value > called unreachable for cases where it makes sense semantically. We use > undefined during development and the warning acts as both a safety net > and a list of todos to fix before the code is ready to merge. > > On Mon, Dec 23, 2019, 12:26 Carter Schonwald > > wrote: > > i agree  with richard here: > > i'd even say it more strongly: > totality is a global property, any "local only " mechanism will > backfire on some valid total code. > > worst of all: any theorem prover extracted code will be rejected :) > (well, at least the sort coq/agda extract to, isabelle/hol code > tends to have less unsafe coerce party time, though still would > likely fail any "local" totally rules of thumb). > > On Mon, Dec 23, 2019 at 10:48 AM Richard Eisenberg > > wrote: > > I have not seen a serious proposal for TotalHaskell before. It > would be a great thing to have, but my guess is that at least > two PhD students would have to be sacrificed to the cause. > There are *many* ways that Haskell is a non-total language. > > Here are a few: > > - general recursion (including definitions like loop = loop) >   - well-founded recursion (where the recursive calls are on > structurally smaller arguments) is ok, though >     - but not on infinite data >   - well-guarded corecursion (like `ones = 1 : ones`) is also ok >   - recursive type-class dictionaries allows (I think) > unbounded recursion > - exceptions > - incomplete pattern matches >   - unless GADT restrictions say that the match is actually total > - incomplete uni-pattern matches >   - unless GADT restrictions say that the match is actually total > - partial record selectors > - non-strictly-positive datatypes > - Typeable allows you to simulate non-strictly-positive > datatypes (see Sec. 7 of > https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs) > - Girard's paradox (because we have Type :: Type), though it > is not known whether this is encodable in Haskell. See > https://link.springer.com/chapter/10.1007/BFb0014058 > - -fdefer-type-errors > > Some of these are easy enough to stamp out, but others may be > harder. And I'm sure I'm missing some cases. I am *not* trying > to say we shouldn't do anything in this direction -- far from > it. However, one should proceed in this direction with eyes open. > > Richard > > > On Dec 23, 2019, at 8:12 AM, Vilem Liepelt > > wrote: > > > > > >> I assume a TotalHaskell pragma was proposed in the past. > Would this help? > > > > Yes, in fact I think this is even better. Does "total" refer > to exhaustive pattern matching and absence of (possible) > exceptions? > > > > We might want to have such a pragma on a > function-by-function basis as well as whole-module. > > > > My company has committed to letting me work on GHC a couple > of days each month, so I'd be up to work on this, although I'd > need someone to hold my hand as I haven't done this before. > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Dec 24 19:57:10 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 24 Dec 2019 14:57:10 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <90f22f36-0bcc-0876-b21a-64fd3af9c858@gmail.com> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> <90f22f36-0bcc-0876-b21a-64fd3af9c858@gmail.com> Message-ID: excellent point! On Tue, Dec 24, 2019 at 11:53 AM Vanessa McHale wrote: > You can use hlint to ban a function (such as undefined) in a particular > codebase. I use it to avoid releasing packages without a real error message. > > Cheers, > Vanessa > On 12/23/19 8:51 PM, Tikhon Jelvis wrote: > > In our codebase at work, undefined had a warning and we have a value > called unreachable for cases where it makes sense semantically. We use > undefined during development and the warning acts as both a safety net and > a list of todos to fix before the code is ready to merge. > > On Mon, Dec 23, 2019, 12:26 Carter Schonwald > wrote: > >> i agree with richard here: >> >> i'd even say it more strongly: >> totality is a global property, any "local only " mechanism will backfire >> on some valid total code. >> >> worst of all: any theorem prover extracted code will be rejected :) >> (well, at least the sort coq/agda extract to, isabelle/hol code tends to >> have less unsafe coerce party time, though still would likely fail any >> "local" totally rules of thumb). >> >> On Mon, Dec 23, 2019 at 10:48 AM Richard Eisenberg >> wrote: >> >>> I have not seen a serious proposal for TotalHaskell before. It would be >>> a great thing to have, but my guess is that at least two PhD students would >>> have to be sacrificed to the cause. There are *many* ways that Haskell is a >>> non-total language. >>> >>> Here are a few: >>> >>> - general recursion (including definitions like loop = loop) >>> - well-founded recursion (where the recursive calls are on >>> structurally smaller arguments) is ok, though >>> - but not on infinite data >>> - well-guarded corecursion (like `ones = 1 : ones`) is also ok >>> - recursive type-class dictionaries allows (I think) unbounded >>> recursion >>> - exceptions >>> - incomplete pattern matches >>> - unless GADT restrictions say that the match is actually total >>> - incomplete uni-pattern matches >>> - unless GADT restrictions say that the match is actually total >>> - partial record selectors >>> - non-strictly-positive datatypes >>> - Typeable allows you to simulate non-strictly-positive datatypes (see >>> Sec. 7 of >>> https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs >>> ) >>> - Girard's paradox (because we have Type :: Type), though it is not >>> known whether this is encodable in Haskell. See >>> https://link.springer.com/chapter/10.1007/BFb0014058 >>> - -fdefer-type-errors >>> >>> Some of these are easy enough to stamp out, but others may be harder. >>> And I'm sure I'm missing some cases. I am *not* trying to say we shouldn't >>> do anything in this direction -- far from it. However, one should proceed >>> in this direction with eyes open. >>> >>> Richard >>> >>> > On Dec 23, 2019, at 8:12 AM, Vilem Liepelt >>> wrote: >>> > >>> > >>> >> I assume a TotalHaskell pragma was proposed in the past. Would this >>> help? >>> > >>> > Yes, in fact I think this is even better. Does "total" refer to >>> exhaustive pattern matching and absence of (possible) exceptions? >>> > >>> > We might want to have such a pragma on a function-by-function basis as >>> well as whole-module. >>> > >>> > My company has committed to letting me work on GHC a couple of days >>> each month, so I'd be up to work on this, although I'd need someone to hold >>> my hand as I haven't done this before. >>> > _______________________________________________ >>> > 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Dec 25 06:22:43 2019 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 25 Dec 2019 01:22:43 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: <32DD0710-73CA-404A-A29C-BD41CEBF9DA0@futurefinance.com> References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> <00A26B87-4C17-43D1-9390-CEC1299A6D3D@richarde.dev> <32DD0710-73CA-404A-A29C-BD41CEBF9DA0@futurefinance.com> Message-ID: I'm much more in favor of pushing folks that want warnings of this sort of behavior towards custom HLint rules for banning behavior (which can be done today, but probably comes across as too weak) or towards seeking a general mechanism to name a set of methods you'd like to explicitly warn about during compilation time (so that mechanism could be more uniformly applied across third-party code bases, but which requires a design and GHC engineering effort) over applying a WARNING pragma as a blunt instrument to this particular problem. (As an aside, let x = x in x can throw a NonTermination exception without ever invoking any explicit throwing mechanism, depending on how nice your runtime system wants to be, so being "exception-free" here is confusing phrasing to me.) WARNING as it stands is far too strong. There are plenty of cases where they are the only thing you can do, due to limitations of the totality checker or invariants that Haskell can't express holding behind your back. A rule of thumbs I've tried to keep in mind towards existing warnings and deprecation efforts is that a WARNING or DEPRECATED pragma that leaves you with no alternative but to listen to the compiler scream even when you are doing your utmost to avoid it short of disabling all warnings is a badly designed warning or deprecation. -Edward On Mon, Dec 23, 2019 at 11:04 AM Vilem Liepelt wrote: > I agree with your assessment, Richard, but my (possibly flawed) > understanding is that in the Haskell community "totality" does not have the > same meaning as in mathematics/PLT—Haskellers use "total" for the property > "doesn't throw non-exhaustive pattern match errors" or perhaps "doesn't > throw any exceptions at all" vs "terminating" for the property "doesn't > loop infinitely". [citation needed] > > Hence I understood Henning's proposal to refer to the notion of > "exception-free". This would already be a very useful property and I > suspect would be easier to solve. Yes, complete pattern matches are > undecidable in the presence of GADTs, but can't we simply build on GHC's > existing heuristics? > > Would this really be a pragma or would it be a language */restriction/* > (heh)? > > Regarding nontermination, I would be grateful if Haskell at least had an > option for explicit let-rec... > > On 23 Dec 2019, at 17:44, Richard Eisenberg wrote: > > GADT restrictions say that the match is actually total > - incomplete uni-pattern matches > - unless GADT restrictions say that the match is actually total > - partial record selectors > - non-strictly-positive datatypes > - Typeable allows you to simulate non-strictly-positive datatypes (see > Sec. 7 of > https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs > ) > - Girard's paradox (because we have Type :: Type), though it is not known > whether this is encodable in Haskell. See > https://link.springer.com/chapter/10.1007/BFb0014058 > - -fdefer-type-errors > > > _______________________________________________ > 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 ekmett at gmail.com Wed Dec 25 06:41:22 2019 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 25 Dec 2019 01:41:22 -0500 Subject: WARNING pragmas in `Prelude.undefined` and `Prelude.error` In-Reply-To: References: <780764A6-D014-4389-BC51-D8664129016A@futurefinance.com> Message-ID: The idiom of using undefined to replace BangPatterns has a few benefits, which is why it gets used in libraries like bytestring. It doesn't require a language extension and applies a bit nicer in macro expansion because it infects one line of your patterns rather than either mangling all pattern matches or relying on subtleties about whether or not the pattern match earlier was enough to 'forget' the strictness of a later pattern when it isn't strict in a subsequent pattern. foo !(Bar x) !(Bar y) = ... foo y w = ... am I strict in w? foo x y | seq x (seq y False) = undefined foo (Bar x) (Bar y) = ... foo y w = ... is definitely strict in w Other usecases are for working with combinators like sizeOf, alignment, bitSize, bitSizeMaybe, finiteBitSize, or doing things like initializing self-referential IORef structures whenever you do have to tie the knot strictly, etc. In the former cases you can argue that the API should change to take a Proxy, then spend a couple of years driving that change process through, as most of them affect the current language report, but in the latter case you're basically stuck with either embracing momentary partiality and knowledge of lack of escape or working with inaccurately weak types after the structure is initialized, forever. -Edward On Mon, Dec 23, 2019 at 11:30 AM Vilem Liepelt wrote: > > > On 22 Dec 2019, at 14:15, Zemyla wrote: > > > > The most common legitimate usage for undefined I have is strictness: > > > > func x y | x `seq` False = undefined > > func x y = ... > > > > There's nothing else that would go there, and when it's compiled, the > reference to undefined disappears. > > Is this (better than | different from) using BangPatterns? > _______________________________________________ > 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 david.feuer at gmail.com Sat Dec 28 19:24:58 2019 From: david.feuer at gmail.com (David Feuer) Date: Sat, 28 Dec 2019 14:24:58 -0500 Subject: Augmented sequence deletion Message-ID: Data.Sequence offers deleteAt :: Int -> Seq a -> Seq a which deletes the element at the given index. Today, I ran into a situation where I wanted to know what was deleted. deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) The closest thing I can find in `containers` is in Data.Map: updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a -> (Maybe a,Map k a) Unfortunately, that function is ugly and strange. A better one, whose name I can't guess at the moment: flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) where a Nothing result means the index was out of bounds. There's also a potential flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> Maybe (f (Seq a)) I'm not sure if flabbergast can be made as fast as deleteLookup, so it's possible we may want both. Any opinions? From zemyla at gmail.com Sat Dec 28 19:59:38 2019 From: zemyla at gmail.com (Zemyla) Date: Sat, 28 Dec 2019 13:59:38 -0600 Subject: Augmented sequence deletion In-Reply-To: References: Message-ID: deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) deleteLookup n q = case Seq.splitAt n q of (ql, qr) -> case Seq.viewl qr of Seq.EmptyL -> Nothing (Seq.:<) a qr' -> Just (a, ql <> qr') If it were written natively, it'd probably use some of the machinery from splitAt. On 13:25, Sat, Dec 28, 2019 David Feuer Data.Sequence offers > > deleteAt :: Int -> Seq a -> Seq a > > which deletes the element at the given index. Today, I ran into a > situation where I wanted to know what was deleted. > > deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) > > The closest thing I can find in `containers` is in Data.Map: > > updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a > -> (Maybe a,Map k a) > > Unfortunately, that function is ugly and strange. A better one, whose > name I can't guess at the moment: > > flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) > > where a Nothing result means the index was out of bounds. There's also > a potential > > flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> > Maybe (f (Seq a)) > > I'm not sure if flabbergast can be made as fast as deleteLookup, so > it's possible we may want both. Any opinions? > _______________________________________________ > 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 david.feuer at gmail.com Sat Dec 28 20:06:21 2019 From: david.feuer at gmail.com (David Feuer) Date: Sat, 28 Dec 2019 15:06:21 -0500 Subject: Augmented sequence deletion In-Reply-To: References: Message-ID: Written natively, it would surely borrow the machinery of deleteAt, which does quite a bit less reshuffling. It's actually a finger-twisted version of a classical 2-3 tree deletion. On Sat, Dec 28, 2019, 2:59 PM Zemyla wrote: > deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) > deleteLookup n q = case Seq.splitAt n q of > (ql, qr) -> case Seq.viewl qr of > Seq.EmptyL -> Nothing > (Seq.:<) a qr' -> Just (a, ql <> qr') > > If it were written natively, it'd probably use some of the machinery from > splitAt. > > On 13:25, Sat, Dec 28, 2019 David Feuer >> Data.Sequence offers >> >> deleteAt :: Int -> Seq a -> Seq a >> >> which deletes the element at the given index. Today, I ran into a >> situation where I wanted to know what was deleted. >> >> deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) >> >> The closest thing I can find in `containers` is in Data.Map: >> >> updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a >> -> (Maybe a,Map k a) >> >> Unfortunately, that function is ugly and strange. A better one, whose >> name I can't guess at the moment: >> >> flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) >> >> where a Nothing result means the index was out of bounds. There's also >> a potential >> >> flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> >> Maybe (f (Seq a)) >> >> I'm not sure if flabbergast can be made as fast as deleteLookup, so >> it's possible we may want both. Any opinions? >> _______________________________________________ >> 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 keith.wygant at gmail.com Sat Dec 28 22:36:14 2019 From: keith.wygant at gmail.com (Keith) Date: Sat, 28 Dec 2019 22:36:14 +0000 Subject: Augmented sequence deletion In-Reply-To: References: Message-ID: <688FF43F-A249-48BA-8EED-FAF65A79ED69@gmail.com> This sounds like 'unconsAt', if 'uncons' isn't already too obtuse. On December 28, 2019 8:06:21 PM UTC, David Feuer wrote: >Written natively, it would surely borrow the machinery of deleteAt, >which >does quite a bit less reshuffling. It's actually a finger-twisted >version >of a classical 2-3 tree deletion. > >On Sat, Dec 28, 2019, 2:59 PM Zemyla wrote: > >> deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) >> deleteLookup n q = case Seq.splitAt n q of >> (ql, qr) -> case Seq.viewl qr of >> Seq.EmptyL -> Nothing >> (Seq.:<) a qr' -> Just (a, ql <> qr') >> >> If it were written natively, it'd probably use some of the machinery >from >> splitAt. >> >> On 13:25, Sat, Dec 28, 2019 David Feuer > >>> Data.Sequence offers >>> >>> deleteAt :: Int -> Seq a -> Seq a >>> >>> which deletes the element at the given index. Today, I ran into a >>> situation where I wanted to know what was deleted. >>> >>> deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) >>> >>> The closest thing I can find in `containers` is in Data.Map: >>> >>> updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k >a >>> -> (Maybe a,Map k a) >>> >>> Unfortunately, that function is ugly and strange. A better one, >whose >>> name I can't guess at the moment: >>> >>> flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, >Seq a) >>> >>> where a Nothing result means the index was out of bounds. There's >also >>> a potential >>> >>> flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> >>> Maybe (f (Seq a)) >>> >>> I'm not sure if flabbergast can be made as fast as deleteLookup, so >>> it's possible we may want both. Any opinions? >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Sun Dec 29 00:25:14 2019 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Sun, 29 Dec 2019 01:25:14 +0100 Subject: Augmented sequence deletion In-Reply-To: References: Message-ID: <62032e82-4fc1-ed3f-ef69-828ce7e89638@ifi.lmu.de> I'd advocate a Swiss army knife like atM :: Applicative m => Int -> (Maybe a -> m (Maybe a)) -> Seq a -> m (Seq a) Then you can get your deleteLookup function by a suitable instance of the effect m. Nothing stands for "index does not point to any element", "Just a" means the index points to value a. On 2019-12-28 20:24, David Feuer wrote: > Data.Sequence offers > > deleteAt :: Int -> Seq a -> Seq a > > which deletes the element at the given index. Today, I ran into a > situation where I wanted to know what was deleted. > > deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) > > The closest thing I can find in `containers` is in Data.Map: > > updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a > -> (Maybe a,Map k a) > > Unfortunately, that function is ugly and strange. A better one, whose > name I can't guess at the moment: > > flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) > > where a Nothing result means the index was out of bounds. There's also > a potential > > flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> > Maybe (f (Seq a)) > > I'm not sure if flabbergast can be made as fast as deleteLookup, so > it's possible we may want both. Any opinions? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From david.feuer at gmail.com Sun Dec 29 00:32:28 2019 From: david.feuer at gmail.com (David Feuer) Date: Sat, 28 Dec 2019 19:32:28 -0500 Subject: Augmented sequence deletion In-Reply-To: <62032e82-4fc1-ed3f-ef69-828ce7e89638@ifi.lmu.de> References: <62032e82-4fc1-ed3f-ef69-828ce7e89638@ifi.lmu.de> Message-ID: That approach works great for maps and sets, but not so well for sequences. If a sequence has ten elements, then you can't really insert a twentieth one. On Sat, Dec 28, 2019, 7:25 PM Andreas Abel wrote: > I'd advocate a Swiss army knife like > > atM > :: Applicative m > => Int > -> (Maybe a -> m (Maybe a)) > -> Seq a -> m (Seq a) > > Then you can get your deleteLookup function by a suitable instance of > the effect m. > > Nothing stands for "index does not point to any element", "Just a" means > the index points to value a. > > On 2019-12-28 20:24, David Feuer wrote: > > Data.Sequence offers > > > > deleteAt :: Int -> Seq a -> Seq a > > > > which deletes the element at the given index. Today, I ran into a > > situation where I wanted to know what was deleted. > > > > deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) > > > > The closest thing I can find in `containers` is in Data.Map: > > > > updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a > > -> (Maybe a,Map k a) > > > > Unfortunately, that function is ugly and strange. A better one, whose > > name I can't guess at the moment: > > > > flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) > > > > where a Nothing result means the index was out of bounds. There's also > > a potential > > > > flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> > > Maybe (f (Seq a)) > > > > I'm not sure if flabbergast can be made as fast as deleteLookup, so > > it's possible we may want both. Any opinions? > > _______________________________________________ > > 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: