From kovanikov at gmail.com Sun Sep 1 05:56:10 2019 From: kovanikov at gmail.com (Dmitrii Kovanikov) Date: Sun, 1 Sep 2019 08:56:10 +0300 Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics In-Reply-To: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> Message-ID: +1 This sounds very useful. I also thought about having this `newtype` in the past and there were even some posts on Reddit about such feature. Basically, after this change, we can start recommending using `Generically` + `DerivingVia` instead of `DefaultSignatures`. It always bothered me that you can have only one default signature and for some reasons it's implemented for generics in almost every package. It just seems too arbitrary and ad-hoc to me. `newtype`s feel like a more natural solution. Instead of relying on whatever `default-signature` provides you can explicitly specify your deriving strategy. On Fri, Aug 30, 2019 at 9:16 PM Alexis King wrote: > Hi all, > > In recent years, the DefaultSignatures extension has seen popular use as a > mechanism for providing derived typeclass instances via GHC.Generics. > Although undeniably useful, I have always felt it is somewhat ugly: it is > mutually exclusive with other, non-Generic default method implementations, > and it can only be used for one Generic deriving mechanism, so > implementations must choose between GHC.Generics and Data.Data. > > Fortunately, with the advent of DerivingVia, there is a better way: simply > attach generic instances to a separate newtype, defined like > > newtype Generically a = Generically { unGenerically :: a } > > instance Generic a => C (Generically a) where > ... > > then derive instances using DerivingVia as follows: > > data Foo = Bar X | Baz Y Z > deriving C via Generically Foo > > The `Generically` name already exists for this purpose in the > `generic-data` package, making it a good candidate name for a newtype in > GHC.Generics (`generic-data` could simply re-export the type with suitably > recent versions of `base`). An alternate name would be the more traditional > `WrappedGeneric`. I don’t have much of a preference either way, but I do > think the `Generically` name is cute, especially when used with DerivingVia. > > I believe this type should be in `base` because it is > > (1) clearly generally useful in the same way that similar newtypes in > `base` like `WrappedMonad` are (and probably even more so), > > (2) extremely lightweight in terms of additional API complexity (it’s just > a newtype), > > (3) isn’t worth depending on a separate package for, encouraging a > proliferation of (possibly name-conflicting) newtypes in individual > packages if it isn’t in `base`, and > > (4) is an opportunity to add instances based on `Generic` for classes > already in `base`. > > Overall, it’s something that would feel right at home in GHC.Generics to > me. > > As a final note, whichever name people prefer, it would of course make > sense to provide an analogous `Generically1` or `WrappedGeneric1` type for > `Generic1` (as `generic-data` does as well). > > Alexis > _______________________________________________ > 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 chessai1996 at gmail.com Sun Sep 1 06:14:56 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 1 Sep 2019 02:14:56 -0400 Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics In-Reply-To: References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> Message-ID: Also, default signatures look dreadful in haddocks. On Sun, Sep 1, 2019, 1:56 AM Dmitrii Kovanikov wrote: > +1 > > This sounds very useful. I also thought about having this `newtype` in the > past and there were even some posts on Reddit about such feature. > > Basically, after this change, we can start recommending using > `Generically` + `DerivingVia` instead of `DefaultSignatures`. It always > bothered me that you can have only one default signature and for some > reasons it's implemented for generics in almost every package. It just > seems too arbitrary and ad-hoc to me. `newtype`s feel like a more natural > solution. Instead of relying on whatever `default-signature` provides you > can explicitly specify your deriving strategy. > > On Fri, Aug 30, 2019 at 9:16 PM Alexis King wrote: > >> Hi all, >> >> In recent years, the DefaultSignatures extension has seen popular use as >> a mechanism for providing derived typeclass instances via GHC.Generics. >> Although undeniably useful, I have always felt it is somewhat ugly: it is >> mutually exclusive with other, non-Generic default method implementations, >> and it can only be used for one Generic deriving mechanism, so >> implementations must choose between GHC.Generics and Data.Data. >> >> Fortunately, with the advent of DerivingVia, there is a better way: >> simply attach generic instances to a separate newtype, defined like >> >> newtype Generically a = Generically { unGenerically :: a } >> >> instance Generic a => C (Generically a) where >> ... >> >> then derive instances using DerivingVia as follows: >> >> data Foo = Bar X | Baz Y Z >> deriving C via Generically Foo >> >> The `Generically` name already exists for this purpose in the >> `generic-data` package, making it a good candidate name for a newtype in >> GHC.Generics (`generic-data` could simply re-export the type with suitably >> recent versions of `base`). An alternate name would be the more traditional >> `WrappedGeneric`. I don’t have much of a preference either way, but I do >> think the `Generically` name is cute, especially when used with DerivingVia. >> >> I believe this type should be in `base` because it is >> >> (1) clearly generally useful in the same way that similar newtypes in >> `base` like `WrappedMonad` are (and probably even more so), >> >> (2) extremely lightweight in terms of additional API complexity (it’s >> just a newtype), >> >> (3) isn’t worth depending on a separate package for, encouraging a >> proliferation of (possibly name-conflicting) newtypes in individual >> packages if it isn’t in `base`, and >> >> (4) is an opportunity to add instances based on `Generic` for classes >> already in `base`. >> >> Overall, it’s something that would feel right at home in GHC.Generics to >> me. >> >> As a final note, whichever name people prefer, it would of course make >> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for >> `Generic1` (as `generic-data` does as well). >> >> Alexis >> _______________________________________________ >> 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 Sun Sep 1 06:22:55 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 1 Sep 2019 09:22:55 +0300 Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics In-Reply-To: References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> Message-ID: Note, that many Generic-derived instances for newtypes are equivalent with GND instance. Generic mechanism is powerful enough to notice newtype special case. > On 1 Sep 2019, at 8.56, Dmitrii Kovanikov wrote: > > +1 > > This sounds very useful. I also thought about having this `newtype` in the past and there were even some posts on Reddit about such feature. > > Basically, after this change, we can start recommending using `Generically` + `DerivingVia` instead of `DefaultSignatures`. It always bothered me that you can have only one default signature and for some reasons it's implemented for generics in almost every package. It just seems too arbitrary and ad-hoc to me. `newtype`s feel like a more natural solution. Instead of relying on whatever `default-signature` provides you can explicitly specify your deriving strategy. > >> On Fri, Aug 30, 2019 at 9:16 PM Alexis King wrote: >> Hi all, >> >> In recent years, the DefaultSignatures extension has seen popular use as a mechanism for providing derived typeclass instances via GHC.Generics. Although undeniably useful, I have always felt it is somewhat ugly: it is mutually exclusive with other, non-Generic default method implementations, and it can only be used for one Generic deriving mechanism, so implementations must choose between GHC.Generics and Data.Data. >> >> Fortunately, with the advent of DerivingVia, there is a better way: simply attach generic instances to a separate newtype, defined like >> >> newtype Generically a = Generically { unGenerically :: a } >> >> instance Generic a => C (Generically a) where >> ... >> >> then derive instances using DerivingVia as follows: >> >> data Foo = Bar X | Baz Y Z >> deriving C via Generically Foo >> >> The `Generically` name already exists for this purpose in the `generic-data` package, making it a good candidate name for a newtype in GHC.Generics (`generic-data` could simply re-export the type with suitably recent versions of `base`). An alternate name would be the more traditional `WrappedGeneric`. I don’t have much of a preference either way, but I do think the `Generically` name is cute, especially when used with DerivingVia. >> >> I believe this type should be in `base` because it is >> >> (1) clearly generally useful in the same way that similar newtypes in `base` like `WrappedMonad` are (and probably even more so), >> >> (2) extremely lightweight in terms of additional API complexity (it’s just a newtype), >> >> (3) isn’t worth depending on a separate package for, encouraging a proliferation of (possibly name-conflicting) newtypes in individual packages if it isn’t in `base`, and >> >> (4) is an opportunity to add instances based on `Generic` for classes already in `base`. >> >> Overall, it’s something that would feel right at home in GHC.Generics to me. >> >> As a final note, whichever name people prefer, it would of course make sense to provide an analogous `Generically1` or `WrappedGeneric1` type for `Generic1` (as `generic-data` does as well). >> >> Alexis >> _______________________________________________ >> 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 ndospark320 at gmail.com Sun Sep 1 09:27:43 2019 From: ndospark320 at gmail.com (Dannyu NDos) Date: Sun, 1 Sep 2019 18:27:43 +0900 Subject: optional definition Message-ID: The current 'one or none' definition breaks the order of elements. It is more Ord-friendly to define it as 'none or one'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Sun Sep 1 13:42:18 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Sun, 1 Sep 2019 09:42:18 -0400 Subject: optional definition In-Reply-To: References: Message-ID: <56dbf190-6edd-f9d1-aa9f-f57b252cb7b3@gmail.com> Link to the definition being discussed: https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#v:optional On 9/1/19 5:27 AM, Dannyu NDos wrote: > The current 'one or none' definition breaks the order of elements. > But `optional` does try, in order, to produce one element before falling back to `Nothing`. optional v = (Just <$> v) <|> pure Nothing -- one or none > It is more Ord-friendly to define it as 'none or one'. Why is it a good thing for "Alternative" to be "Ord-friendly"? "Alternative" has little to do with "Ord" in the first place. Cheers, Li-yao From ekmett at gmail.com Sun Sep 1 14:22:52 2019 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 1 Sep 2019 07:22:52 -0700 Subject: optional definition In-Reply-To: References: Message-ID: It would also render the combinator useless for its normal purpose. optional is used mostly to try to run a parser and to either succeed with its result (wrapped in a Just) or _failing that_ to just return Nothing and carry on. For monads like parsec, the first parse is the one that gets returned, so the definition isn't symmetric in behavior. -Edward On Sun, Sep 1, 2019 at 2:28 AM Dannyu NDos wrote: > The current 'one or none' definition breaks the order of elements. > > It is more Ord-friendly to define it as 'none or one'. > _______________________________________________ > 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 ndospark320 at gmail.com Fri Sep 6 02:09:47 2019 From: ndospark320 at gmail.com (Dannyu NDos) Date: Fri, 6 Sep 2019 11:09:47 +0900 Subject: optional definition In-Reply-To: References: Message-ID: I once used `traverse optional` combined with `catMaybes`. For example: Prelude Control.Applicative Data.Maybe> catMaybes <$> traverse optional [[1,2],[3]] [[1,3],[1],[2,3],[2],[3],[]] This is totally out of order. I think a more natural output is: [[],[3],[1],[1,3],[2],[2,3]] 2019년 9월 1일 (일) 오후 11:23, Edward Kmett 님이 작성: > It would also render the combinator useless for its normal purpose. > > optional is used mostly to try to run a parser and to either succeed with > its result (wrapped in a Just) or _failing that_ to just return Nothing > and carry on. > > For monads like parsec, the first parse is the one that gets returned, so > the definition isn't symmetric in behavior. > > -Edward > > On Sun, Sep 1, 2019 at 2:28 AM Dannyu NDos wrote: > >> The current 'one or none' definition breaks the order of elements. >> >> It is more Ord-friendly to define it as 'none or one'. >> _______________________________________________ >> 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 Fri Sep 6 22:35:40 2019 From: david.feuer at gmail.com (David Feuer) Date: Fri, 6 Sep 2019 18:35:40 -0400 Subject: optional definition In-Reply-To: References: Message-ID: When you have a MonadPlus instance satisfying the left distribution law [*]: (m <|> n) >>= k = (m >>= k) <|> (n >>= k) then (Just <$> m <|> pure Nothing) >>= k = (Just <$> m >>= k) <|> (pure Nothing >>= k) = (m >>= k . Just) <|> k Nothing (pure Nothing <|> Just <$> m) >>= k = k Nothing <|> (m >>= k . Just) These look pretty similar, so there's no one obviously correct choice. You could imagine using one to indicate that you prefer to include the optional part, but that you're okay without it, and the other to indicate that you only want to include the optional part if necessary. Suppose, instead, that you have an Alternative instance that satisfies the left catch law: pure x <|> m = pure x This is very common for parsers that don't backtrack by default, along with types like Maybe and IO. Now pure Nothing <|> Just <$> m = pure Nothing Oops! That's not useful at all! Now, let's look at another important practical matter. Lots of real code in the wild uses `optional`. Almost all of this code would break if the semantics were changed. So there is basically no chance that will ever happen. You could make an argument for including the other version too, but I don't yet see a compelling use case. [*] https://en.wikibooks.org/wiki/Haskell/Alternative_and_MonadPlus#Other_suggested_laws On Thu, Sep 5, 2019, 10:10 PM Dannyu NDos wrote: > I once used `traverse optional` combined with `catMaybes`. For example: > > Prelude Control.Applicative Data.Maybe> catMaybes <$> traverse optional > [[1,2],[3]] > [[1,3],[1],[2,3],[2],[3],[]] > > This is totally out of order. I think a more natural output is: > > [[],[3],[1],[1,3],[2],[2,3]] > > 2019년 9월 1일 (일) 오후 11:23, Edward Kmett 님이 작성: > >> It would also render the combinator useless for its normal purpose. >> >> optional is used mostly to try to run a parser and to either succeed with >> its result (wrapped in a Just) or _failing that_ to just return Nothing >> and carry on. >> >> For monads like parsec, the first parse is the one that gets returned, so >> the definition isn't symmetric in behavior. >> >> -Edward >> >> On Sun, Sep 1, 2019 at 2:28 AM Dannyu NDos wrote: >> >>> The current 'one or none' definition breaks the order of elements. >>> >>> It is more Ord-friendly to define it as 'none or one'. >>> _______________________________________________ >>> 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 hvriedel at gmail.com Sat Sep 7 11:28:20 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 7 Sep 2019 13:28:20 +0200 Subject: Package take over: regex-{base,compat,pcre,posix} Message-ID: Hello everyone, I tried to contact Christopher Kuklewicz on May 10, 2019 via the two email addresses associated with his packages (also CC'ed in this email) but got no response. I hereby invoke the protocol as per https://wiki.haskell.org/Taking_over_a_package to take over the packages mentioned in the subject line which haven't seen any release to Hackage since May 2012 as the most recent upload events for these packages show: 2012-05-30T21:44:34Z ChrisKuklewicz regex-pcre-0.94.4-r0 2012-05-20T16:46:16Z ChrisKuklewicz regex-pcre-0.94.3-r0 2012-05-20T16:35:59Z ChrisKuklewicz regex-posix-0.95.2-r0 2011-05-09T18:01:58Z ChrisKuklewicz regex-compat-0.95.1-r0 2011-05-09T15:55:55Z ChrisKuklewicz regex-posix-0.95.1-r0 2011-05-09T15:29:42Z ChrisKuklewicz regex-posix-0.95.0-r0 2010-07-20T10:58:10Z ChrisKuklewicz regex-posix-0.94.4-r0 2010-06-11T23:01:36Z ChrisKuklewicz regex-posix-0.94.2-r0 2010-06-11T23:00:42Z ChrisKuklewicz regex-pcre-0.94.2-r0 2010-06-11T22:59:26Z ChrisKuklewicz regex-compat-0.93.1-r0 2010-06-11T22:58:19Z ChrisKuklewicz regex-base-0.93.2-r0 This package take-over is also tracked at https://github.com/haskell-infra/hackage-trustees/issues/238 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sat Sep 7 16:43:21 2019 From: danburton.email at gmail.com (Dan Burton) Date: Sat, 7 Sep 2019 09:43:21 -0700 Subject: Package take over: regex-{base,compat,pcre,posix} In-Reply-To: References: Message-ID: +1 Would appreciate these being maintained; I switched a test suite from test-framework to tasty due to a ghc 8.8 MonadFail issue somewhere in this dependency chain. On Sat, Sep 7, 2019, 04:28 Herbert Valerio Riedel wrote: > Hello everyone, > > I tried to contact Christopher Kuklewicz on May 10, 2019 via the two email > addresses associated with his packages (also CC'ed in this email) but got > no response. > > I hereby invoke the protocol as per > https://wiki.haskell.org/Taking_over_a_package to take over the packages > mentioned in the subject line which haven't seen any release to Hackage > since May 2012 as the most recent upload events for these packages show: > > 2012-05-30T21:44:34Z ChrisKuklewicz regex-pcre-0.94.4-r0 > 2012-05-20T16:46:16Z ChrisKuklewicz regex-pcre-0.94.3-r0 > 2012-05-20T16:35:59Z ChrisKuklewicz regex-posix-0.95.2-r0 > 2011-05-09T18:01:58Z ChrisKuklewicz regex-compat-0.95.1-r0 > 2011-05-09T15:55:55Z ChrisKuklewicz regex-posix-0.95.1-r0 > 2011-05-09T15:29:42Z ChrisKuklewicz regex-posix-0.95.0-r0 > 2010-07-20T10:58:10Z ChrisKuklewicz regex-posix-0.94.4-r0 > 2010-06-11T23:01:36Z ChrisKuklewicz regex-posix-0.94.2-r0 > 2010-06-11T23:00:42Z ChrisKuklewicz regex-pcre-0.94.2-r0 > 2010-06-11T22:59:26Z ChrisKuklewicz regex-compat-0.93.1-r0 > 2010-06-11T22:58:19Z ChrisKuklewicz regex-base-0.93.2-r0 > > This package take-over is also tracked at > https://github.com/haskell-infra/hackage-trustees/issues/238 > _______________________________________________ > 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 taylor at fausak.me Sat Sep 7 17:48:15 2019 From: taylor at fausak.me (Taylor Fausak) Date: Sat, 07 Sep 2019 13:48:15 -0400 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: <5ec1554e-cb70-4352-aab3-a02be088024b@www.fastmail.com> I'm still waiting to hear anything at all from the CLC. In the meantime I published the list-singleton library to provide this function: https://taylor.fausak.me/2019/09/07/list-singleton/ On Wed, Aug 28, 2019, at 3:57 PM, Keith wrote: > For what it's worth, when starting out I found the disconnect between list sugar and list constructor/destructors extremely confusing. > In retrospect it seems pretty silly, but I could not figure out how lists were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes like [x, xs] were common. > When I finally realized that I could construct lists with the list constuctors, I started using them exclusively. > > Simplcity and straightforwardness help understanding. It was much easier for me to understand a singleton list as (x : []) than [x]. Having to deal with '(singleton x)' (at the time not knowing the definition of 'singleton') would have been another layer of confusion. > > I get that 'singleton' is library design, since in shows up in Map, Array, Set, etc. But for me trying to use lists, it would have only been useful if I defined it myself as a way to learn that constuctors are fuctions, and that 'singleton' means 'single'. > > On August 23, 2019 7:56:41 AM UTC, Sven Panne wrote: >> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe : >>> >>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne wrote: >>>> I think there's a significant difference between "little helper" and "the monomorphic function that is used to implement `pure`" - with a slightly different framing, we might be able to come to an agreement that both the monomorphic an polymorphic versions of this function are useful in different contexts. [...] >> >> I think we can agree that we disagree here. ;-) My brain is too small to remember the names of myriads of trivial helpers, so I very much prefer general, orthogonal things. In our case: If we have a general, polymorphic function (often from a type class), just use that. If for some reason (rarely!) I want a more monomorphic function, I can just add a plain old type signature somewhere (no need for funky language extensions like type applications). This radically reduces the number of things one has to remember. In our case: Know type classes + know a way to make things more monomorphic. >> >>>> >>> My guiding principle for API design is that one should always expose the fundamental building blocks as a low-level API, and then provide a smaller interface for the common use cases. Typeclass instances are no different - they are the general interface that allows us to invoke what is ultimately a monomorphic, low-level building block function in a polymorphic context. >> >> This is exactly the opposite API design principle I have: Do not expose the monomorphic functions if they are already in a type class. You can easily reconstruct them as a library user via type signtures if this is really needed (still haven't seen many convincing examples of that), but you can' do it the other way round. Less things exposed, no generality/use cases lost => easier to remember. >> >> The thing we can probably agree on: API design is hard and it's not an exact science, more a kind of art which is assessed in a subjective way... :-) >>> > > Keith > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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 Sun Sep 8 05:58:55 2019 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 7 Sep 2019 22:58:55 -0700 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: To grant some insight into what is going on behind closed doors. I figured I'd unpack a bit of it here. The current resolution is to treat this as step one in a longer maneuver. *We'll be adding *singleton* to *Data.List*, immediately.* The headache has really been the issue mentioned above wherein Data.List has historically been treated as an unqualified export that shouldn't clash with the Prelude in any way. This is mostly a historical accident and doesn't really match up with the way any of the other "container" like modules are expected to be used. It has led to the somewhat messy state of dozens of other combinators in Data.List such as foldr having to be generalized by the Foldable/Traversable Proposal and other language warts starting to accumulate over time. It is disproportionately difficult to add things to Data.List, so we're going to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a sufficient forcing function. Expanding the API of Data.List is acting as that forcing function. *We are going to be switching the usage pattern for *Data.List* to expect a qualified or explicit import list like *Data.Text, Data.ByteString, Data.Set ,* etc.* This also helps allow for easier expansion of Data.List, which has been pretty stagnant other than a non-report-specified uncons slipping in stealthily in GHC 7.10. It also helps ameliorate any long term concerns with this taking a name, as it is now something placed in a module where name collisions are okay, as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to accumulate enough data to show that breakage this one combinator would introduce was pretty minor after all, so we're going to go ahead with adding singleton before the rest of this happens. To get *there*, we'll need a slightly longer timeline, and some support from GHC HQ to craft an appropriate warning. This will allow us to monomorphize the combinators in Data.List yielding a sane ending state that doesn't require a PhD in the History of Haskell to fully understand, and we'll be able to retire GHC.OldList once an appropriate 3-release policy compatible migration plan has been fully hammered out. Normally, I'd wait until we had a full plan with all the migration issues posted rather than shooting off half-cocked like this, but I wanted to be clear about what was causing the communication delay. -Edward On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: > For what it's worth, when starting out I found the disconnect between list > sugar and list constructor/destructors extremely confusing. > In retrospect it seems pretty silly, but I could not figure out how lists > were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes > like [x, xs] were common. > When I finally realized that I could construct lists with the list > constuctors, I started using them exclusively. > > Simplcity and straightforwardness help understanding. It was much easier > for me to understand a singleton list as (x : []) than [x]. Having to deal > with '(singleton x)' (at the time not knowing the definition of > 'singleton') would have been another layer of confusion. > > I get that 'singleton' is library design, since in shows up in Map, Array, > Set, etc. But for me trying to use lists, it would have only been useful if > I defined it myself as a way to learn that constuctors are fuctions, and > that 'singleton' means 'single'. > > On August 23, 2019 7:56:41 AM UTC, Sven Panne wrote: >> >> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe < >> kris.nuttycombe at gmail.com>: >> >>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne wrote: >>> >>>> I think there's a significant difference between "little helper" and >>>> "the monomorphic function that is used to implement `pure`" - with a >>>> slightly different framing, we might be able to come to an agreement that >>>> both the monomorphic an polymorphic versions of this function are useful in >>>> different contexts. [...] >>>> >>> >> I think we can agree that we disagree here. ;-) My brain is too small to >> remember the names of myriads of trivial helpers, so I very much prefer >> general, orthogonal things. In our case: If we have a general, polymorphic >> function (often from a type class), just use that. If for some reason >> (rarely!) I want a more monomorphic function, I can just add a plain old >> type signature somewhere (no need for funky language extensions like type >> applications). This radically reduces the number of things one has to >> remember. In our case: Know type classes + know a way to make things more >> monomorphic. >> >> >>> My guiding principle for API design is that one should always expose the >>> fundamental building blocks as a low-level API, and then provide a smaller >>> interface for the common use cases. Typeclass instances are no different - >>> they are the general interface that allows us to invoke what is ultimately >>> a monomorphic, low-level building block function in a polymorphic context. >>> >> >> This is exactly the opposite API design principle I have: Do not expose >> the monomorphic functions if they are already in a type class. You can >> easily reconstruct them as a library user via type signtures if this is >> really needed (still haven't seen many convincing examples of that), but >> you can' do it the other way round. Less things exposed, no generality/use >> cases lost => easier to remember. >> >> The thing we can probably agree on: API design is hard and it's not an >> exact science, more a kind of art which is assessed in a subjective way... >> :-) >> >>> > Keith > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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 helmut.schmidt.4711 at gmail.com Sun Sep 8 06:53:32 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Sun, 8 Sep 2019 06:53:32 +0000 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: Am So., 8. Sept. 2019 um 05:59 Uhr schrieb Edward Kmett : > To grant some insight into what is going on behind closed doors. I figured > I'd unpack a bit of it here. > Why is it necessary this gets discussed behind closed doors in the first place? Why can't we get more insight into the decision process of such a highly controversial proposal? > > The current resolution is to treat this as step one in a longer maneuver. > > *We'll be adding *singleton* to *Data.List*, immediately.* > > The headache has really been the issue mentioned above wherein Data.List > has historically been treated as an unqualified export that shouldn't clash > with the Prelude in any way. > > This is mostly a historical accident and doesn't really match up with the > way any of the other "container" like modules are expected to be used. It > has led to the somewhat messy state of dozens of other combinators in Data.List > such as foldr having to be generalized by the Foldable/Traversable > Proposal and other language warts starting to accumulate over time. It is > disproportionately difficult to add things to Data.List, so we're going > to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a > sufficient forcing function. Expanding the API of Data.List is acting as > that forcing function. > > *We are going to be switching the usage pattern for *Data.List* to expect > a qualified or explicit import list like *Data.Text, Data.ByteString, > Data.Set,* etc.* > > This also helps allow for easier expansion of Data.List, which has been > pretty stagnant other than a non-report-specified uncons slipping in > stealthily in GHC 7.10. > > It also helps ameliorate any long term concerns with this taking a name, > as it is now something placed in a module where name collisions are okay, > as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to > accumulate enough data to show that breakage this one combinator would > introduce was pretty minor after all, so we're going to go ahead with > adding singleton before the rest of this happens. > > To get *there*, we'll need a slightly longer timeline, and some support > from GHC HQ to craft an appropriate warning. This will allow us to > monomorphize the combinators in Data.List yielding a sane ending state > that doesn't require a PhD in the History of Haskell to fully understand, > and we'll be able to retire GHC.OldList once an appropriate 3-release > policy compatible migration plan has been fully hammered out. > > Normally, I'd wait until we had a full plan with all the migration issues > posted rather than shooting off half-cocked like this, but I wanted to be > clear about what was causing the communication delay. > > -Edward > > On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: > >> For what it's worth, when starting out I found the disconnect between >> list sugar and list constructor/destructors extremely confusing. >> In retrospect it seems pretty silly, but I could not figure out how lists >> were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes >> like [x, xs] were common. >> When I finally realized that I could construct lists with the list >> constuctors, I started using them exclusively. >> >> Simplcity and straightforwardness help understanding. It was much easier >> for me to understand a singleton list as (x : []) than [x]. Having to deal >> with '(singleton x)' (at the time not knowing the definition of >> 'singleton') would have been another layer of confusion. >> >> I get that 'singleton' is library design, since in shows up in Map, >> Array, Set, etc. But for me trying to use lists, it would have only been >> useful if I defined it myself as a way to learn that constuctors are >> fuctions, and that 'singleton' means 'single'. >> >> On August 23, 2019 7:56:41 AM UTC, Sven Panne >> wrote: >>> >>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe < >>> kris.nuttycombe at gmail.com>: >>> >>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne wrote: >>>> >>>>> I think there's a significant difference between "little helper" and >>>>> "the monomorphic function that is used to implement `pure`" - with a >>>>> slightly different framing, we might be able to come to an agreement that >>>>> both the monomorphic an polymorphic versions of this function are useful in >>>>> different contexts. [...] >>>>> >>>> >>> I think we can agree that we disagree here. ;-) My brain is too small to >>> remember the names of myriads of trivial helpers, so I very much prefer >>> general, orthogonal things. In our case: If we have a general, polymorphic >>> function (often from a type class), just use that. If for some reason >>> (rarely!) I want a more monomorphic function, I can just add a plain old >>> type signature somewhere (no need for funky language extensions like type >>> applications). This radically reduces the number of things one has to >>> remember. In our case: Know type classes + know a way to make things more >>> monomorphic. >>> >>> >>>> My guiding principle for API design is that one should always expose >>>> the fundamental building blocks as a low-level API, and then provide a >>>> smaller interface for the common use cases. Typeclass instances are no >>>> different - they are the general interface that allows us to invoke what is >>>> ultimately a monomorphic, low-level building block function in a >>>> polymorphic context. >>>> >>> >>> This is exactly the opposite API design principle I have: Do not expose >>> the monomorphic functions if they are already in a type class. You can >>> easily reconstruct them as a library user via type signtures if this is >>> really needed (still haven't seen many convincing examples of that), but >>> you can' do it the other way round. Less things exposed, no generality/use >>> cases lost => easier to remember. >>> >>> The thing we can probably agree on: API design is hard and it's not an >>> exact science, more a kind of art which is assessed in a subjective way... >>> :-) >>> >>>> >> Keith >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> 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 ryan.gl.scott at gmail.com Sun Sep 8 12:01:30 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 8 Sep 2019 08:01:30 -0400 Subject: Proposal: Add singleton function to Data.List module Message-ID: > Meanwhile, Ryan GL Scott managed to > accumulate enough data to show that breakage this one combinator would > introduce was pretty minor after all, so we're going to go ahead with > adding singleton before the rest of this happens. In case you're curious what this data looks like: I compiled GHC 8.6.5, but with the singleton function added to Data.List, and built a decently large variety of libraries from Hackage to see what would break. When I was done with this informal experiment, my ~/.cabal/store directory for this version of GHC had 523 entries, which provides a loose upper bound on the number of libraries that successfully built (there are some duplicate entries). You can view these store entries at [1]. Of these ~500 or so libraries, there were a grant total of three that did not build out of the box: * blank-canvas-0.7 * ghc-lib-parser-8.8.0.20190723 * pandoc-2.7.3 Of course, this experiment is not exhaustive—there are many other libraries out there, and there is also lots of code that is not on Hackage. Nevertheless, the overall percentage of libraries that broke was surprisingly small, and certainly much smaller than my initial estimate. Ryan S. ---- [1] https://gitlab.haskell.org/snippets/1474 From danburton.email at gmail.com Mon Sep 9 00:46:01 2019 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 8 Sep 2019 17:46:01 -0700 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: > monomorphize the combinators in Data.List... retire GHC.OldList Sounds great! Thanks for working on these improvements. -- Dan Burton On Sat, Sep 7, 2019 at 10:59 PM Edward Kmett wrote: > To grant some insight into what is going on behind closed doors. I figured > I'd unpack a bit of it here. > > The current resolution is to treat this as step one in a longer maneuver. > > *We'll be adding *singleton* to *Data.List*, immediately.* > > The headache has really been the issue mentioned above wherein Data.List > has historically been treated as an unqualified export that shouldn't clash > with the Prelude in any way. > > This is mostly a historical accident and doesn't really match up with the > way any of the other "container" like modules are expected to be used. It > has led to the somewhat messy state of dozens of other combinators in Data.List > such as foldr having to be generalized by the Foldable/Traversable > Proposal and other language warts starting to accumulate over time. It is > disproportionately difficult to add things to Data.List, so we're going > to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a > sufficient forcing function. Expanding the API of Data.List is acting as > that forcing function. > > *We are going to be switching the usage pattern for *Data.List* to expect > a qualified or explicit import list like *Data.Text, Data.ByteString, > Data.Set,* etc.* > > This also helps allow for easier expansion of Data.List, which has been > pretty stagnant other than a non-report-specified uncons slipping in > stealthily in GHC 7.10. > > It also helps ameliorate any long term concerns with this taking a name, > as it is now something placed in a module where name collisions are okay, > as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to > accumulate enough data to show that breakage this one combinator would > introduce was pretty minor after all, so we're going to go ahead with > adding singleton before the rest of this happens. > > To get *there*, we'll need a slightly longer timeline, and some support > from GHC HQ to craft an appropriate warning. This will allow us to > monomorphize the combinators in Data.List yielding a sane ending state > that doesn't require a PhD in the History of Haskell to fully understand, > and we'll be able to retire GHC.OldList once an appropriate 3-release > policy compatible migration plan has been fully hammered out. > > Normally, I'd wait until we had a full plan with all the migration issues > posted rather than shooting off half-cocked like this, but I wanted to be > clear about what was causing the communication delay. > > -Edward > > On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: > >> For what it's worth, when starting out I found the disconnect between >> list sugar and list constructor/destructors extremely confusing. >> In retrospect it seems pretty silly, but I could not figure out how lists >> were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes >> like [x, xs] were common. >> When I finally realized that I could construct lists with the list >> constuctors, I started using them exclusively. >> >> Simplcity and straightforwardness help understanding. It was much easier >> for me to understand a singleton list as (x : []) than [x]. Having to deal >> with '(singleton x)' (at the time not knowing the definition of >> 'singleton') would have been another layer of confusion. >> >> I get that 'singleton' is library design, since in shows up in Map, >> Array, Set, etc. But for me trying to use lists, it would have only been >> useful if I defined it myself as a way to learn that constuctors are >> fuctions, and that 'singleton' means 'single'. >> >> On August 23, 2019 7:56:41 AM UTC, Sven Panne >> wrote: >>> >>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe < >>> kris.nuttycombe at gmail.com>: >>> >>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne wrote: >>>> >>>>> I think there's a significant difference between "little helper" and >>>>> "the monomorphic function that is used to implement `pure`" - with a >>>>> slightly different framing, we might be able to come to an agreement that >>>>> both the monomorphic an polymorphic versions of this function are useful in >>>>> different contexts. [...] >>>>> >>>> >>> I think we can agree that we disagree here. ;-) My brain is too small to >>> remember the names of myriads of trivial helpers, so I very much prefer >>> general, orthogonal things. In our case: If we have a general, polymorphic >>> function (often from a type class), just use that. If for some reason >>> (rarely!) I want a more monomorphic function, I can just add a plain old >>> type signature somewhere (no need for funky language extensions like type >>> applications). This radically reduces the number of things one has to >>> remember. In our case: Know type classes + know a way to make things more >>> monomorphic. >>> >>> >>>> My guiding principle for API design is that one should always expose >>>> the fundamental building blocks as a low-level API, and then provide a >>>> smaller interface for the common use cases. Typeclass instances are no >>>> different - they are the general interface that allows us to invoke what is >>>> ultimately a monomorphic, low-level building block function in a >>>> polymorphic context. >>>> >>> >>> This is exactly the opposite API design principle I have: Do not expose >>> the monomorphic functions if they are already in a type class. You can >>> easily reconstruct them as a library user via type signtures if this is >>> really needed (still haven't seen many convincing examples of that), but >>> you can' do it the other way round. Less things exposed, no generality/use >>> cases lost => easier to remember. >>> >>> The thing we can probably agree on: API design is hard and it's not an >>> exact science, more a kind of art which is assessed in a subjective way... >>> :-) >>> >>>> >> Keith >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> 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 eacameron at gmail.com Mon Sep 9 01:56:21 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Sun, 8 Sep 2019 21:56:21 -0400 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: Agreed this an even better outcome than I had hoped for! On Sun, Sep 8, 2019 at 8:46 PM Dan Burton wrote: > > monomorphize the combinators in Data.List... retire GHC.OldList > > Sounds great! Thanks for working on these improvements. > > -- Dan Burton > > > On Sat, Sep 7, 2019 at 10:59 PM Edward Kmett wrote: > >> To grant some insight into what is going on behind closed doors. I >> figured I'd unpack a bit of it here. >> >> The current resolution is to treat this as step one in a longer maneuver. >> >> *We'll be adding *singleton* to *Data.List*, immediately.* >> >> The headache has really been the issue mentioned above wherein Data.List >> has historically been treated as an unqualified export that shouldn't clash >> with the Prelude in any way. >> >> This is mostly a historical accident and doesn't really match up with the >> way any of the other "container" like modules are expected to be used. It >> has led to the somewhat messy state of dozens of other combinators in Data.List >> such as foldr having to be generalized by the Foldable/Traversable >> Proposal and other language warts starting to accumulate over time. It is >> disproportionately difficult to add things to Data.List, so we're going >> to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a >> sufficient forcing function. Expanding the API of Data.List is acting as >> that forcing function. >> >> *We are going to be switching the usage pattern for *Data.List* to >> expect a qualified or explicit import list like *Data.Text, >> Data.ByteString, Data.Set,* etc.* >> >> This also helps allow for easier expansion of Data.List, which has been >> pretty stagnant other than a non-report-specified uncons slipping in >> stealthily in GHC 7.10. >> >> It also helps ameliorate any long term concerns with this taking a name, >> as it is now something placed in a module where name collisions are okay, >> as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to >> accumulate enough data to show that breakage this one combinator would >> introduce was pretty minor after all, so we're going to go ahead with >> adding singleton before the rest of this happens. >> >> To get *there*, we'll need a slightly longer timeline, and some support >> from GHC HQ to craft an appropriate warning. This will allow us to >> monomorphize the combinators in Data.List yielding a sane ending state >> that doesn't require a PhD in the History of Haskell to fully understand, >> and we'll be able to retire GHC.OldList once an appropriate 3-release >> policy compatible migration plan has been fully hammered out. >> >> Normally, I'd wait until we had a full plan with all the migration issues >> posted rather than shooting off half-cocked like this, but I wanted to be >> clear about what was causing the communication delay. >> >> -Edward >> >> On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: >> >>> For what it's worth, when starting out I found the disconnect between >>> list sugar and list constructor/destructors extremely confusing. >>> In retrospect it seems pretty silly, but I could not figure out how >>> lists were consumed as (x : xs) but often produced with [x, x1, ...]. >>> Mistakes like [x, xs] were common. >>> When I finally realized that I could construct lists with the list >>> constuctors, I started using them exclusively. >>> >>> Simplcity and straightforwardness help understanding. It was much easier >>> for me to understand a singleton list as (x : []) than [x]. Having to deal >>> with '(singleton x)' (at the time not knowing the definition of >>> 'singleton') would have been another layer of confusion. >>> >>> I get that 'singleton' is library design, since in shows up in Map, >>> Array, Set, etc. But for me trying to use lists, it would have only been >>> useful if I defined it myself as a way to learn that constuctors are >>> fuctions, and that 'singleton' means 'single'. >>> >>> On August 23, 2019 7:56:41 AM UTC, Sven Panne >>> wrote: >>>> >>>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe < >>>> kris.nuttycombe at gmail.com>: >>>> >>>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne >>>>> wrote: >>>>> >>>>>> I think there's a significant difference between "little helper" and >>>>>> "the monomorphic function that is used to implement `pure`" - with a >>>>>> slightly different framing, we might be able to come to an agreement that >>>>>> both the monomorphic an polymorphic versions of this function are useful in >>>>>> different contexts. [...] >>>>>> >>>>> >>>> I think we can agree that we disagree here. ;-) My brain is too small >>>> to remember the names of myriads of trivial helpers, so I very much prefer >>>> general, orthogonal things. In our case: If we have a general, polymorphic >>>> function (often from a type class), just use that. If for some reason >>>> (rarely!) I want a more monomorphic function, I can just add a plain old >>>> type signature somewhere (no need for funky language extensions like type >>>> applications). This radically reduces the number of things one has to >>>> remember. In our case: Know type classes + know a way to make things more >>>> monomorphic. >>>> >>>> >>>>> My guiding principle for API design is that one should always expose >>>>> the fundamental building blocks as a low-level API, and then provide a >>>>> smaller interface for the common use cases. Typeclass instances are no >>>>> different - they are the general interface that allows us to invoke what is >>>>> ultimately a monomorphic, low-level building block function in a >>>>> polymorphic context. >>>>> >>>> >>>> This is exactly the opposite API design principle I have: Do not expose >>>> the monomorphic functions if they are already in a type class. You can >>>> easily reconstruct them as a library user via type signtures if this is >>>> really needed (still haven't seen many convincing examples of that), but >>>> you can' do it the other way round. Less things exposed, no generality/use >>>> cases lost => easier to remember. >>>> >>>> The thing we can probably agree on: API design is hard and it's not an >>>> exact science, more a kind of art which is assessed in a subjective way... >>>> :-) >>>> >>>>> >>> Keith >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>> _______________________________________________ >>> 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 Sep 9 02:38:01 2019 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 8 Sep 2019 19:38:01 -0700 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: https://groups.google.com/forum/#!forum/haskell-core-libraries should link to the CLC mailing list archive. As far as I can tell it should be public. -Edward On Sat, Sep 7, 2019 at 11:53 PM Helmut Schmidt < helmut.schmidt.4711 at gmail.com> wrote: > Am So., 8. Sept. 2019 um 05:59 Uhr schrieb Edward Kmett >: > >> To grant some insight into what is going on behind closed doors. I >> figured I'd unpack a bit of it here. >> > > Why is it necessary this gets discussed behind closed doors in the first > place? Why can't we get more insight into the decision process of such a > highly controversial proposal? > > >> >> The current resolution is to treat this as step one in a longer maneuver. >> >> *We'll be adding *singleton* to *Data.List*, immediately.* >> >> The headache has really been the issue mentioned above wherein Data.List >> has historically been treated as an unqualified export that shouldn't clash >> with the Prelude in any way. >> >> This is mostly a historical accident and doesn't really match up with the >> way any of the other "container" like modules are expected to be used. It >> has led to the somewhat messy state of dozens of other combinators in Data.List >> such as foldr having to be generalized by the Foldable/Traversable >> Proposal and other language warts starting to accumulate over time. It is >> disproportionately difficult to add things to Data.List, so we're going >> to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a >> sufficient forcing function. Expanding the API of Data.List is acting as >> that forcing function. >> >> *We are going to be switching the usage pattern for *Data.List* to >> expect a qualified or explicit import list like *Data.Text, >> Data.ByteString, Data.Set,* etc.* >> >> This also helps allow for easier expansion of Data.List, which has been >> pretty stagnant other than a non-report-specified uncons slipping in >> stealthily in GHC 7.10. >> >> It also helps ameliorate any long term concerns with this taking a name, >> as it is now something placed in a module where name collisions are okay, >> as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to >> accumulate enough data to show that breakage this one combinator would >> introduce was pretty minor after all, so we're going to go ahead with >> adding singleton before the rest of this happens. >> >> To get *there*, we'll need a slightly longer timeline, and some support >> from GHC HQ to craft an appropriate warning. This will allow us to >> monomorphize the combinators in Data.List yielding a sane ending state >> that doesn't require a PhD in the History of Haskell to fully understand, >> and we'll be able to retire GHC.OldList once an appropriate 3-release >> policy compatible migration plan has been fully hammered out. >> >> Normally, I'd wait until we had a full plan with all the migration issues >> posted rather than shooting off half-cocked like this, but I wanted to be >> clear about what was causing the communication delay. >> >> -Edward >> >> On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: >> >>> For what it's worth, when starting out I found the disconnect between >>> list sugar and list constructor/destructors extremely confusing. >>> In retrospect it seems pretty silly, but I could not figure out how >>> lists were consumed as (x : xs) but often produced with [x, x1, ...]. >>> Mistakes like [x, xs] were common. >>> When I finally realized that I could construct lists with the list >>> constuctors, I started using them exclusively. >>> >>> Simplcity and straightforwardness help understanding. It was much easier >>> for me to understand a singleton list as (x : []) than [x]. Having to deal >>> with '(singleton x)' (at the time not knowing the definition of >>> 'singleton') would have been another layer of confusion. >>> >>> I get that 'singleton' is library design, since in shows up in Map, >>> Array, Set, etc. But for me trying to use lists, it would have only been >>> useful if I defined it myself as a way to learn that constuctors are >>> fuctions, and that 'singleton' means 'single'. >>> >>> On August 23, 2019 7:56:41 AM UTC, Sven Panne >>> wrote: >>>> >>>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe < >>>> kris.nuttycombe at gmail.com>: >>>> >>>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne >>>>> wrote: >>>>> >>>>>> I think there's a significant difference between "little helper" and >>>>>> "the monomorphic function that is used to implement `pure`" - with a >>>>>> slightly different framing, we might be able to come to an agreement that >>>>>> both the monomorphic an polymorphic versions of this function are useful in >>>>>> different contexts. [...] >>>>>> >>>>> >>>> I think we can agree that we disagree here. ;-) My brain is too small >>>> to remember the names of myriads of trivial helpers, so I very much prefer >>>> general, orthogonal things. In our case: If we have a general, polymorphic >>>> function (often from a type class), just use that. If for some reason >>>> (rarely!) I want a more monomorphic function, I can just add a plain old >>>> type signature somewhere (no need for funky language extensions like type >>>> applications). This radically reduces the number of things one has to >>>> remember. In our case: Know type classes + know a way to make things more >>>> monomorphic. >>>> >>>> >>>>> My guiding principle for API design is that one should always expose >>>>> the fundamental building blocks as a low-level API, and then provide a >>>>> smaller interface for the common use cases. Typeclass instances are no >>>>> different - they are the general interface that allows us to invoke what is >>>>> ultimately a monomorphic, low-level building block function in a >>>>> polymorphic context. >>>>> >>>> >>>> This is exactly the opposite API design principle I have: Do not expose >>>> the monomorphic functions if they are already in a type class. You can >>>> easily reconstruct them as a library user via type signtures if this is >>>> really needed (still haven't seen many convincing examples of that), but >>>> you can' do it the other way round. Less things exposed, no generality/use >>>> cases lost => easier to remember. >>>> >>>> The thing we can probably agree on: API design is hard and it's not an >>>> exact science, more a kind of art which is assessed in a subjective way... >>>> :-) >>>> >>>>> >>> Keith >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>> _______________________________________________ >>> 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 asr at eafit.edu.co Mon Sep 9 15:49:04 2019 From: asr at eafit.edu.co (Andres Sicard Ramirez) Date: Mon, 9 Sep 2019 15:49:04 +0000 Subject: Package take over: regex-{base,compat,pcre,posix} In-Reply-To: References: Message-ID: +1. In Agda we are waiting that regex-base supports GHC 8.8.1 (see https://github.com/ChrisKuklewicz/regex-tdfa/issues/23). On Sat, 7 Sep 2019 at 06:29, Herbert Valerio Riedel > wrote: Hello everyone, I tried to contact Christopher Kuklewicz on May 10, 2019 via the two email addresses associated with his packages (also CC'ed in this email) but got no response. I hereby invoke the protocol as per https://wiki.haskell.org/Taking_over_a_package to take over the packages mentioned in the subject line which haven't seen any release to Hackage since May 2012 as the most recent upload events for these packages show: 2012-05-30T21:44:34Z ChrisKuklewicz regex-pcre-0.94.4-r0 2012-05-20T16:46:16Z ChrisKuklewicz regex-pcre-0.94.3-r0 2012-05-20T16:35:59Z ChrisKuklewicz regex-posix-0.95.2-r0 2011-05-09T18:01:58Z ChrisKuklewicz regex-compat-0.95.1-r0 2011-05-09T15:55:55Z ChrisKuklewicz regex-posix-0.95.1-r0 2011-05-09T15:29:42Z ChrisKuklewicz regex-posix-0.95.0-r0 2010-07-20T10:58:10Z ChrisKuklewicz regex-posix-0.94.4-r0 2010-06-11T23:01:36Z ChrisKuklewicz regex-posix-0.94.2-r0 2010-06-11T23:00:42Z ChrisKuklewicz regex-pcre-0.94.2-r0 2010-06-11T22:59:26Z ChrisKuklewicz regex-compat-0.93.1-r0 2010-06-11T22:58:19Z ChrisKuklewicz regex-base-0.93.2-r0 This package take-over is also tracked at https://github.com/haskell-infra/hackage-trustees/issues/238 La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Andrés -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor at fausak.me Mon Sep 9 22:30:02 2019 From: taylor at fausak.me (Taylor Fausak) Date: Mon, 09 Sep 2019 18:30:02 -0400 Subject: Proposal: Add singleton function to Data.List module In-Reply-To: References: <5D59678C.6030003@exmail.nottingham.ac.uk> <55EB779D-809B-4686-AA4F-3B23BEBED8C3@gmail.com> Message-ID: <9f3d0da3-35ac-4cbd-bbd3-ecb803f221db@www.fastmail.com> Hooray! I'm happy to hear that my proposal has been accepted and `singleton` will be added to `Data.List` in the next major release of GHC. I'm also excited about making functions in `Data.List` monomorphic to lists. I look forward to that change! I'd like to take a moment to thank my team at ITProTV for motivating this proposal. I'd also like to thank the community, both here and elsewhere, for the spirited discussion about this proposal. And finally I'd like to thank the Core Libraries Committee for ultimately decided on this proposal. I appreciate all of you! Lastly, should I submit a patch for this? I would be happy to, but the code involved is minimal and I don't mind if someone else wants to actually commit it. You can see the code and documentation that I would commit here: https://hackage.haskell.org/package/list-singleton-1.0.0.2/docs/Data-List-Singleton.html#v:singleton On Sun, Sep 8, 2019, at 10:38 PM, Edward Kmett wrote: > https://groups.google.com/forum/#!forum/haskell-core-libraries should link to the CLC mailing list archive. As far as I can tell it should be public. > > -Edward > > On Sat, Sep 7, 2019 at 11:53 PM Helmut Schmidt wrote: >> >> Am So., 8. Sept. 2019 um 05:59 Uhr schrieb Edward Kmett : >>> To grant some insight into what is going on behind closed doors. I figured I'd unpack a bit of it here. >> >> Why is it necessary this gets discussed behind closed doors in the first place? Why can't we get more insight into the decision process of such a highly controversial proposal? >> >>> >>> The current resolution is to treat this as step one in a longer maneuver. >>> >>> *We'll be adding *singleton* to *Data.List*, immediately.* >>> >>> The headache has really been the issue mentioned above wherein Data.List has historically been treated as an unqualified export that shouldn't clash with the Prelude in any way. >>> >>> This is mostly a historical accident and doesn't really match up with the way any of the other "container" like modules are expected to be used. It has led to the somewhat messy state of dozens of other combinators in Data.List such as foldr having to be generalized by the Foldable/Traversable Proposal and other language warts starting to accumulate over time. It is disproportionately difficult to add things to Data.List, so we're going to fix that. -- We'd intended to fix that wart since GHC 7.10, but lacked a sufficient forcing function. Expanding the API of Data.List is acting as that forcing function. >>> >>> *We are going to be switching the usage pattern for *Data.List* to expect a qualified or explicit import list like *Data.Text, Data.ByteString, Data.Set,* etc.* >>> >>> This also helps allow for easier expansion of Data.List, which has been pretty stagnant other than a non-report-specified uncons slipping in stealthily in GHC 7.10. >>> >>> >>> It also helps ameliorate any long term concerns with this taking a name, as it is now something placed in a module where name collisions are okay, as usage is qualified or explicit. Meanwhile, Ryan GL Scott managed to accumulate enough data to show that breakage this one combinator would introduce was pretty minor after all, so we're going to go ahead with adding singleton before the rest of this happens. >>> >>> >>> >>> To get *there*, we'll need a slightly longer timeline, and some support from GHC HQ to craft an appropriate warning. This will allow us to monomorphize the combinators in Data.List yielding a sane ending state that doesn't require a PhD in the History of Haskell to fully understand, and we'll be able to retire GHC.OldList once an appropriate 3-release policy compatible migration plan has been fully hammered out. >>> >>> Normally, I'd wait until we had a full plan with all the migration issues posted rather than shooting off half-cocked like this, but I wanted to be clear about what was causing the communication delay. >>> >>> -Edward >>> >>> On Wed, Aug 28, 2019 at 12:57 PM Keith wrote: >>>> For what it's worth, when starting out I found the disconnect between list sugar and list constructor/destructors extremely confusing. >>>> In retrospect it seems pretty silly, but I could not figure out how lists were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes like [x, xs] were common. >>>> When I finally realized that I could construct lists with the list constuctors, I started using them exclusively. >>>> >>>> Simplcity and straightforwardness help understanding. It was much easier for me to understand a singleton list as (x : []) than [x]. Having to deal with '(singleton x)' (at the time not knowing the definition of 'singleton') would have been another layer of confusion. >>>> >>>> I get that 'singleton' is library design, since in shows up in Map, Array, Set, etc. But for me trying to use lists, it would have only been useful if I defined it myself as a way to learn that constuctors are fuctions, and that 'singleton' means 'single'. >>>> >>>> On August 23, 2019 7:56:41 AM UTC, Sven Panne wrote: >>>>> Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe : >>>>>> >>>>>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne wrote: >>>>>>> I think there's a significant difference between "little helper" and "the monomorphic function that is used to implement `pure`" - with a slightly different framing, we might be able to come to an agreement that both the monomorphic an polymorphic versions of this function are useful in different contexts. [...] >>>>> >>>>> I think we can agree that we disagree here. ;-) My brain is too small to remember the names of myriads of trivial helpers, so I very much prefer general, orthogonal things. In our case: If we have a general, polymorphic function (often from a type class), just use that. If for some reason (rarely!) I want a more monomorphic function, I can just add a plain old type signature somewhere (no need for funky language extensions like type applications). This radically reduces the number of things one has to remember. In our case: Know type classes + know a way to make things more monomorphic. >>>>> >>>>>>> >>>>>> My guiding principle for API design is that one should always expose the fundamental building blocks as a low-level API, and then provide a smaller interface for the common use cases. Typeclass instances are no different - they are the general interface that allows us to invoke what is ultimately a monomorphic, low-level building block function in a polymorphic context. >>>>> >>>>> This is exactly the opposite API design principle I have: Do not expose the monomorphic functions if they are already in a type class. You can easily reconstruct them as a library user via type signtures if this is really needed (still haven't seen many convincing examples of that), but you can' do it the other way round. Less things exposed, no generality/use cases lost => easier to remember. >>>>> >>>>> The thing we can probably agree on: API design is hard and it's not an exact science, more a kind of art which is assessed in a subjective way... :-) >>>>>> >>>> >>>> Keith >>>> -- >>>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>>> _______________________________________________ >>>> 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 david.feuer at gmail.com Tue Sep 10 21:52:47 2019 From: david.feuer at gmail.com (David Feuer) Date: Tue, 10 Sep 2019 17:52:47 -0400 Subject: Proposal: add `on` to the Prelude Message-ID: Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function whose implementation is barely longer than the import. And it's a really good function too! Can we please add it to the Prelude? on :: (b -> b -> c) -> (a -> b) -> a -> a -> c (.*.) `on` f = \x y -> f x .*. f y -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Tue Sep 10 22:25:55 2019 From: chessai1996 at gmail.com (chessai .) Date: Tue, 10 Sep 2019 18:25:55 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: +1 On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: > Every time I reach for Data.Function.on, I feel like a total dolt for > having to import a module to get a function whose implementation is barely > longer than the import. And it's a really good function too! Can we please > add it to the Prelude? > > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c > (.*.) `on` f = \x y -> f x .*. f y > _______________________________________________ > 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 helmut.schmidt.4711 at gmail.com Tue Sep 10 22:41:54 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Tue, 10 Sep 2019 22:41:54 +0000 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Am Di., 10. Sept. 2019 um 21:53 Uhr schrieb David Feuer < david.feuer at gmail.com>: > Every time I reach for Data.Function.on, I feel like a total dolt for > having to import a module to get a function whose implementation is barely > longer than the import. And it's a really good function too! Can we please > add it to the Prelude? > Agreed. This function makes only sense to have if the cost of getting it into scope doesn't outweigh its benefit and therefore I support this proposal which makes a lot more sense than the pointless singleton proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.trinkle at gmail.com Tue Sep 10 22:42:31 2019 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Tue, 10 Sep 2019 18:42:31 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: One note: this does conflict with some other libraries, for instance GTK2HS On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: > +1 > > On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: > >> Every time I reach for Data.Function.on, I feel like a total dolt for >> having to import a module to get a function whose implementation is barely >> longer than the import. And it's a really good function too! Can we please >> add it to the Prelude? >> >> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >> (.*.) `on` f = \x y -> f x .*. f y >> _______________________________________________ >> 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 david.feuer at gmail.com Tue Sep 10 22:59:26 2019 From: david.feuer at gmail.com (David Feuer) Date: Tue, 10 Sep 2019 18:59:26 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Indeed, there are a lot more conflicts than I'd have expected. Ignoring functions with the same type, Hoogle shows this name in the below packages. I have no sense of the overall significance of the specific packages or (equally importantly) of the `on` function within each. haskell-gi-base: on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) => object -> SignalProxy object info -> HaskellCallbackType info -> m SignalHandlerId brick: on :: Color -> Color -> Attr esqueletto: on :: SqlExpr (Value Bool) -> SqlQuery () relational-query (both): on :: MonadQuery m => Predicate Flat -> m () on :: MonadQuery m => QueryA m (Predicate Flat) () threepenny-gui: on :: (element -> Event a) -> element -> (a -> UI void) -> UI () miso: on :: MisoString -> Decoder r -> (r -> action) -> Attribute action wild-bind: on :: i -> v -> Binder i v () massiv-io: on :: Pixel X Bit selda-postgresql: on :: Text -> Text -> PGConnectInfo On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle wrote: > One note: this does conflict with some other libraries, for instance GTK2HS > > On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: > >> +1 >> >> On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: >> >>> Every time I reach for Data.Function.on, I feel like a total dolt for >>> having to import a module to get a function whose implementation is barely >>> longer than the import. And it's a really good function too! Can we please >>> add it to the Prelude? >>> >>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>> (.*.) `on` f = \x y -> f x .*. f y >>> _______________________________________________ >>> 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 eacameron at gmail.com Wed Sep 11 01:32:29 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Tue, 10 Sep 2019 21:32:29 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy language. Anyone who isn't willing to just write their own mini-Prelude should be ready to import things like `on`. Why isn't `for` exported in Prelude? What about `&`? Both of these are extremely useful and common, even moreso than *on*! And their implementation is *even shorter*. It's a slippery slope. On Tue, Sep 10, 2019 at 6:59 PM David Feuer wrote: > Indeed, there are a lot more conflicts than I'd have expected. Ignoring > functions with the same type, Hoogle shows this name in the below packages. > I have no sense of the overall significance of the specific packages or > (equally importantly) of the `on` function within each. > > haskell-gi-base: > on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) > => object -> SignalProxy object info -> HaskellCallbackType info -> m > SignalHandlerId > > brick: > on :: Color -> Color -> Attr > > esqueletto: > on :: SqlExpr (Value Bool) -> SqlQuery () > > relational-query (both): > on :: MonadQuery m => Predicate Flat -> m () > on :: MonadQuery m => QueryA m (Predicate Flat) () > > threepenny-gui: > on :: (element -> Event a) -> element -> (a -> UI void) -> UI () > > miso: > on :: MisoString -> Decoder r -> (r -> action) -> Attribute action > > wild-bind: > on :: i -> v -> Binder i v () > > massiv-io: > on :: Pixel X Bit > > selda-postgresql: > on :: Text -> Text -> PGConnectInfo > > > On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle wrote: > >> One note: this does conflict with some other libraries, for instance >> GTK2HS >> >> On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: >> >>> +1 >>> >>> On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: >>> >>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>> having to import a module to get a function whose implementation is barely >>>> longer than the import. And it's a really good function too! Can we please >>>> add it to the Prelude? >>>> >>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>> (.*.) `on` f = \x y -> f x .*. f y >>>> _______________________________________________ >>>> 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 chessai1996 at gmail.com Wed Sep 11 01:41:19 2019 From: chessai1996 at gmail.com (chessai .) Date: Tue, 10 Sep 2019 21:41:19 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: I would also prefer if (&) and `for` were exported from the Prelude. On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron wrote: > Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy > language. Anyone who isn't willing to just write their own mini-Prelude > should be ready to import things like `on`. Why isn't `for` exported in > Prelude? What about `&`? Both of these are extremely useful and common, > even moreso than *on*! And their implementation is *even shorter*. It's a > slippery slope. > > On Tue, Sep 10, 2019 at 6:59 PM David Feuer wrote: > >> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >> functions with the same type, Hoogle shows this name in the below packages. >> I have no sense of the overall significance of the specific packages or >> (equally importantly) of the `on` function within each. >> >> haskell-gi-base: >> on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) >> => object -> SignalProxy object info -> HaskellCallbackType info -> m >> SignalHandlerId >> >> brick: >> on :: Color -> Color -> Attr >> >> esqueletto: >> on :: SqlExpr (Value Bool) -> SqlQuery () >> >> relational-query (both): >> on :: MonadQuery m => Predicate Flat -> m () >> on :: MonadQuery m => QueryA m (Predicate Flat) () >> >> threepenny-gui: >> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >> >> miso: >> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >> >> wild-bind: >> on :: i -> v -> Binder i v () >> >> massiv-io: >> on :: Pixel X Bit >> >> selda-postgresql: >> on :: Text -> Text -> PGConnectInfo >> >> >> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >> wrote: >> >>> One note: this does conflict with some other libraries, for instance >>> GTK2HS >>> >>> On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: >>> >>>> +1 >>>> >>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>> wrote: >>>> >>>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>>> having to import a module to get a function whose implementation is barely >>>>> longer than the import. And it's a really good function too! Can we please >>>>> add it to the Prelude? >>>>> >>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>> _______________________________________________ >>>>> 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 eacameron at gmail.com Wed Sep 11 01:50:46 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Tue, 10 Sep 2019 21:50:46 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Part of me would too...but I just don't know when this line of reasoning stops. Do we add (>>>) and (<<<) from Category too? Then (&&&)? Of course then we might want first, second... Oh and (<$) isn't exported but ($>) is? Fix that too. Then come join, fix, void, when, unless, bool, fromMaybe..... I've come to the conclusion that Prelude should err on the side of very small because Haskell is just too diverse a place to expect everyone to agree on all these little things. We should all be making project-specific Preludes instead IMO. On Tue, Sep 10, 2019 at 9:41 PM chessai . wrote: > I would also prefer if (&) and `for` were exported from the Prelude. > > On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron wrote: > >> Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy >> language. Anyone who isn't willing to just write their own mini-Prelude >> should be ready to import things like `on`. Why isn't `for` exported in >> Prelude? What about `&`? Both of these are extremely useful and common, >> even moreso than *on*! And their implementation is *even shorter*. It's a >> slippery slope. >> >> On Tue, Sep 10, 2019 at 6:59 PM David Feuer >> wrote: >> >>> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >>> functions with the same type, Hoogle shows this name in the below packages. >>> I have no sense of the overall significance of the specific packages or >>> (equally importantly) of the `on` function within each. >>> >>> haskell-gi-base: >>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>> SignalHandlerId >>> >>> brick: >>> on :: Color -> Color -> Attr >>> >>> esqueletto: >>> on :: SqlExpr (Value Bool) -> SqlQuery () >>> >>> relational-query (both): >>> on :: MonadQuery m => Predicate Flat -> m () >>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>> >>> threepenny-gui: >>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>> >>> miso: >>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>> >>> wild-bind: >>> on :: i -> v -> Binder i v () >>> >>> massiv-io: >>> on :: Pixel X Bit >>> >>> selda-postgresql: >>> on :: Text -> Text -> PGConnectInfo >>> >>> >>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>> wrote: >>> >>>> One note: this does conflict with some other libraries, for instance >>>> GTK2HS >>>> >>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>> wrote: >>>>> >>>>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>>>> having to import a module to get a function whose implementation is barely >>>>>> longer than the import. And it's a really good function too! Can we please >>>>>> add it to the Prelude? >>>>>> >>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>> _______________________________________________ >>>>>> 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 Wed Sep 11 02:18:44 2019 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 10 Sep 2019 19:18:44 -0700 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: The number of name conflicts here has me rather conflicted. To date, we've been treating the Prelude is a very precious common namespace. Every name it takes is a significant cost because now every other use of the name, pre-existing or not, has to explicitly _hide_ the import from the Prelude, not just in their library code, but in all the code that uses the library. By comparison, the Data.List.singleton issue was comparatively clash-free as most uses of a combinator with the same name were already qualified, and we were able to mitigate the remaining issues, by deciding that the module in question was intended to become qualified after a short cycle, so no "global" name is being used up. Here, we're finding several conflicting combinators, and the cost is significantly higher for each of the existing consumers of that name to work around. It strikes me that in the end there'd be a lot of churn, as all existing users of conflicting versions of this very short punchy name would have to move to a new name or endure a ton of Prelude hiding clauses all over their code, in both library and consumer code. This leaves me inclined to a -1. There are combinators I'm somewhat inclined to push into Prelude after an appropriate referendum, e.g. traverse_ or sequence_ which do a lot of work and are quite conspicuous in their absence, when a worse-for-many-applications but comparable tool is closer to hand, but the slight pain of explicitly importing 'on' seems pretty reasonable given the combination of its somewhat confusing at first idiomatic usage, and the somewhat broadly spread existing name conflicts. -Edward On Tue, Sep 10, 2019 at 3:59 PM David Feuer wrote: > Indeed, there are a lot more conflicts than I'd have expected. Ignoring > functions with the same type, Hoogle shows this name in the below packages. > I have no sense of the overall significance of the specific packages or > (equally importantly) of the `on` function within each. > > haskell-gi-base: > on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) > => object -> SignalProxy object info -> HaskellCallbackType info -> m > SignalHandlerId > > brick: > on :: Color -> Color -> Attr > > esqueletto: > on :: SqlExpr (Value Bool) -> SqlQuery () > > relational-query (both): > on :: MonadQuery m => Predicate Flat -> m () > on :: MonadQuery m => QueryA m (Predicate Flat) () > > threepenny-gui: > on :: (element -> Event a) -> element -> (a -> UI void) -> UI () > > miso: > on :: MisoString -> Decoder r -> (r -> action) -> Attribute action > > wild-bind: > on :: i -> v -> Binder i v () > > massiv-io: > on :: Pixel X Bit > > selda-postgresql: > on :: Text -> Text -> PGConnectInfo > > > On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle wrote: > >> One note: this does conflict with some other libraries, for instance >> GTK2HS >> >> On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: >> >>> +1 >>> >>> On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: >>> >>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>> having to import a module to get a function whose implementation is barely >>>> longer than the import. And it's a really good function too! Can we please >>>> add it to the Prelude? >>>> >>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>> (.*.) `on` f = \x y -> f x .*. f y >>>> _______________________________________________ >>>> 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 david.feuer at gmail.com Wed Sep 11 02:20:18 2019 From: david.feuer at gmail.com (David Feuer) Date: Tue, 10 Sep 2019 22:20:18 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: I agree with your general conservatism, but I think some of these things are not like the others. I like `on` for the Prelude because, despite its size, it carries with it the idea of carrying a relationship between two values through a function. Notably, for *any* function f, eq `on` f defines a decidable equivalence relation if eq does. cmp `on` f defines a decidable partial order if cmp does. d `on` f is a pseudometric if d is. What a beautiful and useful concept! I find it much harder to get excited about the idea of flipping function application. On Tue, Sep 10, 2019, 9:50 PM Elliot Cameron wrote: > Part of me would too...but I just don't know when this line of reasoning > stops. Do we add (>>>) and (<<<) from Category too? Then (&&&)? Of course > then we might want first, second... Oh and (<$) isn't exported but ($>) is? > Fix that too. Then come join, fix, void, when, unless, bool, fromMaybe..... > I've come to the conclusion that Prelude should err on the side of very > small because Haskell is just too diverse a place to expect everyone to > agree on all these little things. We should all be making project-specific > Preludes instead IMO. > > On Tue, Sep 10, 2019 at 9:41 PM chessai . wrote: > >> I would also prefer if (&) and `for` were exported from the Prelude. >> >> On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron wrote: >> >>> Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy >>> language. Anyone who isn't willing to just write their own mini-Prelude >>> should be ready to import things like `on`. Why isn't `for` exported in >>> Prelude? What about `&`? Both of these are extremely useful and common, >>> even moreso than *on*! And their implementation is *even shorter*. It's a >>> slippery slope. >>> >>> On Tue, Sep 10, 2019 at 6:59 PM David Feuer >>> wrote: >>> >>>> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >>>> functions with the same type, Hoogle shows this name in the below packages. >>>> I have no sense of the overall significance of the specific packages or >>>> (equally importantly) of the `on` function within each. >>>> >>>> haskell-gi-base: >>>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>>> SignalHandlerId >>>> >>>> brick: >>>> on :: Color -> Color -> Attr >>>> >>>> esqueletto: >>>> on :: SqlExpr (Value Bool) -> SqlQuery () >>>> >>>> relational-query (both): >>>> on :: MonadQuery m => Predicate Flat -> m () >>>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>>> >>>> threepenny-gui: >>>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>>> >>>> miso: >>>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>>> >>>> wild-bind: >>>> on :: i -> v -> Binder i v () >>>> >>>> massiv-io: >>>> on :: Pixel X Bit >>>> >>>> selda-postgresql: >>>> on :: Text -> Text -> PGConnectInfo >>>> >>>> >>>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>>> wrote: >>>> >>>>> One note: this does conflict with some other libraries, for instance >>>>> GTK2HS >>>>> >>>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>>> wrote: >>>>>> >>>>>>> Every time I reach for Data.Function.on, I feel like a total dolt >>>>>>> for having to import a module to get a function whose implementation is >>>>>>> barely longer than the import. And it's a really good function too! Can we >>>>>>> please add it to the Prelude? >>>>>>> >>>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>>> _______________________________________________ >>>>>>> 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 eacameron at gmail.com Wed Sep 11 04:14:12 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 11 Sep 2019 00:14:12 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: That's certainly true but I'm not sure what that has to do with being in Prelude. If anything, I'd expect Prelude to be home to the *least* exciting things because no one wants to bother talking about them. On Tue, Sep 10, 2019, 10:20 PM David Feuer wrote: > I agree with your general conservatism, but I think some of these things > are not like the others. I like `on` for the Prelude because, despite its > size, it carries with it the idea of carrying a relationship between two > values through a function. Notably, for *any* function f, > > eq `on` f defines a decidable equivalence relation if eq does. > cmp `on` f defines a decidable partial order if cmp does. > d `on` f is a pseudometric if d is. > > What a beautiful and useful concept! I find it much harder to get excited > about the idea of flipping function application. > > On Tue, Sep 10, 2019, 9:50 PM Elliot Cameron wrote: > >> Part of me would too...but I just don't know when this line of reasoning >> stops. Do we add (>>>) and (<<<) from Category too? Then (&&&)? Of course >> then we might want first, second... Oh and (<$) isn't exported but ($>) is? >> Fix that too. Then come join, fix, void, when, unless, bool, fromMaybe..... >> I've come to the conclusion that Prelude should err on the side of very >> small because Haskell is just too diverse a place to expect everyone to >> agree on all these little things. We should all be making project-specific >> Preludes instead IMO. >> >> On Tue, Sep 10, 2019 at 9:41 PM chessai . wrote: >> >>> I would also prefer if (&) and `for` were exported from the Prelude. >>> >>> On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron >>> wrote: >>> >>>> Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy >>>> language. Anyone who isn't willing to just write their own mini-Prelude >>>> should be ready to import things like `on`. Why isn't `for` exported in >>>> Prelude? What about `&`? Both of these are extremely useful and common, >>>> even moreso than *on*! And their implementation is *even shorter*. It's a >>>> slippery slope. >>>> >>>> On Tue, Sep 10, 2019 at 6:59 PM David Feuer >>>> wrote: >>>> >>>>> Indeed, there are a lot more conflicts than I'd have expected. >>>>> Ignoring functions with the same type, Hoogle shows this name in the below >>>>> packages. I have no sense of the overall significance of the specific >>>>> packages or (equally importantly) of the `on` function within each. >>>>> >>>>> haskell-gi-base: >>>>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>>>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>>>> SignalHandlerId >>>>> >>>>> brick: >>>>> on :: Color -> Color -> Attr >>>>> >>>>> esqueletto: >>>>> on :: SqlExpr (Value Bool) -> SqlQuery () >>>>> >>>>> relational-query (both): >>>>> on :: MonadQuery m => Predicate Flat -> m () >>>>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>>>> >>>>> threepenny-gui: >>>>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>>>> >>>>> miso: >>>>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>>>> >>>>> wild-bind: >>>>> on :: i -> v -> Binder i v () >>>>> >>>>> massiv-io: >>>>> on :: Pixel X Bit >>>>> >>>>> selda-postgresql: >>>>> on :: Text -> Text -> PGConnectInfo >>>>> >>>>> >>>>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>>>> wrote: >>>>> >>>>>> One note: this does conflict with some other libraries, for instance >>>>>> GTK2HS >>>>>> >>>>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>>>> wrote: >>>>>>> >>>>>>>> Every time I reach for Data.Function.on, I feel like a total dolt >>>>>>>> for having to import a module to get a function whose implementation is >>>>>>>> barely longer than the import. And it's a really good function too! Can we >>>>>>>> please add it to the Prelude? >>>>>>>> >>>>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>>>> _______________________________________________ >>>>>>>> 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 helmut.schmidt.4711 at gmail.com Wed Sep 11 06:08:27 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Wed, 11 Sep 2019 06:08:27 +0000 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: +1 Am Mi., 11. Sept. 2019 um 01:41 Uhr schrieb chessai . : > I would also prefer if (&) and `for` were exported from the Prelude. > > On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron wrote: > >> Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy >> language. Anyone who isn't willing to just write their own mini-Prelude >> should be ready to import things like `on`. Why isn't `for` exported in >> Prelude? What about `&`? Both of these are extremely useful and common, >> even moreso than *on*! And their implementation is *even shorter*. It's a >> slippery slope. >> >> On Tue, Sep 10, 2019 at 6:59 PM David Feuer >> wrote: >> >>> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >>> functions with the same type, Hoogle shows this name in the below packages. >>> I have no sense of the overall significance of the specific packages or >>> (equally importantly) of the `on` function within each. >>> >>> haskell-gi-base: >>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>> SignalHandlerId >>> >>> brick: >>> on :: Color -> Color -> Attr >>> >>> esqueletto: >>> on :: SqlExpr (Value Bool) -> SqlQuery () >>> >>> relational-query (both): >>> on :: MonadQuery m => Predicate Flat -> m () >>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>> >>> threepenny-gui: >>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>> >>> miso: >>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>> >>> wild-bind: >>> on :: i -> v -> Binder i v () >>> >>> massiv-io: >>> on :: Pixel X Bit >>> >>> selda-postgresql: >>> on :: Text -> Text -> PGConnectInfo >>> >>> >>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>> wrote: >>> >>>> One note: this does conflict with some other libraries, for instance >>>> GTK2HS >>>> >>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>> wrote: >>>>> >>>>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>>>> having to import a module to get a function whose implementation is barely >>>>>> longer than the import. And it's a really good function too! Can we please >>>>>> add it to the Prelude? >>>>>> >>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>> _______________________________________________ >>>>>> 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 helmut.schmidt.4711 at gmail.com Wed Sep 11 06:17:21 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Wed, 11 Sep 2019 06:17:21 +0000 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Am Mi., 11. Sept. 2019 um 02:18 Uhr schrieb Edward Kmett : > There are combinators I'm somewhat inclined to push into Prelude after an > appropriate referendum, e.g. traverse_ or sequence_ which do a lot of work > and are quite conspicuous in their absence, when a > worse-for-many-applications but comparable tool is closer to hand, but the > slight pain of explicitly importing 'on' seems pretty reasonable given the > combination of its somewhat confusing at first idiomatic usage, and the > somewhat broadly spread existing name conflicts. > This slight pain of writing "import Data.Function (on)" as you call is why I and probably most other people don't bother using "on". But why is such a trivial combinator that's cheaper to define locally than to import even defined in the base library if the pain of using it outweighs its usefulness and there's just a handful of people at best using it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From helmut.schmidt.4711 at gmail.com Wed Sep 11 06:36:24 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Wed, 11 Sep 2019 06:36:24 +0000 Subject: Proposal: Add cons function to Data.List module Message-ID: For more or less the same reasons that "singleton" was considered worth being added to Data.List I propose to add "cons" to Data.List as well. ## Motivation Sometimes it is convenient to have a function to prepend an element to a list in pointless style code. But of the existing ways none of them are as clear as a separate monomorphic function. - "( : )" is subjectively ugly - "(\x xs -> x : xs)" is syntactically noisy Purescript also has a "Cons" function so why can't we have one too? We already have "Data.List.uncons" and so for symmetry one would also expect to find "Data.List.cons". Many sequence like APIs have a "cons" function such as https://www.stackage.org/haddock/nightly-2019-09-11/vector-0.12.0.3/Data-Vector.html#v:cons I can't be the only that wants this function, right? ## Proposal Add cons :: x -> [x] -> [x] cons = (:) to Data.List -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Sep 11 08:13:02 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 11 Sep 2019 09:13:02 +0100 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt wrote: > I can't be the only that wants this function, right? You're not the only one! I would also like this function. In fact, only yesterday I found myself writing ( x : ) <$> recurse xs I would have preferred cons x <$> recurse xs +1 to adding cons :: x -> [x] -> [x] to Data.List. Ollie From taylor at fausak.me Wed Sep 11 11:20:59 2019 From: taylor at fausak.me (Taylor Fausak) Date: Wed, 11 Sep 2019 07:20:59 -0400 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: I suspect this proposal was not made in good faith. I feel like it was meant to make fun of my list singleton proposal. In spite of that, I am in favor of this proposal. One of the (very minor!) problems with lists in Haskell is that they can’t be documented with Haddock because they’re part of the syntax. For example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list constructor. You will find `cons` from the `extra` package, which I think suggests that this proposal is a good idea. +1 > On Sep 11, 2019, at 4:13 AM, Oliver Charles wrote: > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > wrote: > >> I can't be the only that wants this function, right? > > You're not the only one! I would also like this function. In fact, > only yesterday I found myself writing > > ( x : ) <$> recurse xs > > I would have preferred > > cons x <$> recurse xs > > +1 to adding cons :: x -> [x] -> [x] to Data.List. > > Ollie > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From kovanikov at gmail.com Wed Sep 11 11:32:05 2019 From: kovanikov at gmail.com (Dmitrii Kovanikov) Date: Wed, 11 Sep 2019 15:32:05 +0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: +1 from me We export `on` from `relude` by default and didn't have any problems so far: * http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on I believe that this proposal hits the same wall like all other proposals regarding changes to the standard library — it's not clear, what are Prelude goals. Should it be minimal and provide only fundamental things, or should it enforce commonly used idioms? I think that the `on` function from this proposal is the most widely used version of any other function with the same name. When I see `on` in the code, I first expect the version from `base`, not from some external library with a different type. Implementing your own `on` in your library and forcing users to use it makes code hard to read and reason about. Especially when people are using implicit imports — good luck figuring out which one `on` is used! I believe that if `on` was already imported by `Prelude`, fewer people would introduce identifiers with this name. Which means that exporting `on` from `Prelude` is an excellent thing to do if `Prelude` wants to force idiomatic usage of this function. On Wed, Sep 11, 2019 at 1:53 AM David Feuer wrote: > Every time I reach for Data.Function.on, I feel like a total dolt for > having to import a module to get a function whose implementation is barely > longer than the import. And it's a really good function too! Can we please > add it to the Prelude? > > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c > (.*.) `on` f = \x y -> f x .*. f y > _______________________________________________ > 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 hvriedel at gmail.com Wed Sep 11 11:53:04 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 11 Sep 2019 13:53:04 +0200 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Hello everyone, To provide another data-point; in my "Prelude module replacement" package http://hackage.haskell.org/package/Prelude which encodes a common standard vocabulary from `base` I've observed in my own projects over the years where I often keep a "local prelude" module for the purpose of establishing a project-specific common vocabulary. Under these constraints, `on` as well as `&` happens to be such a common vocabulary which I expect to have in my default scope, and thus is reexported from the "Prelude" module: http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21 But then again, since it's so easy to implement your own opinionated "Prelude" replacement (either project-local or as a package on Hackage), and subjective tastes differ greatly as the recent controversial "singleton" proposal showed, and even though reexporting `on` from Prelude has an objective merit in contrast, and I can definitely sympathise with *this* proposal, I'm not sure if we really need to modify `base` to achieve the stated goal of having a more convenient function in scope. But to be clear; at this point, I'm neither for nor against the proposal to reexport names from Data.Function from the `base` Prelude. On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov wrote: > +1 from me > > We export `on` from `relude` by default and didn't have any problems so > far: > > * > http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on > > I believe that this proposal hits the same wall like all other proposals > regarding changes to the standard library — it's not clear, what are > Prelude goals. Should it be minimal and provide only fundamental things, or > should it enforce commonly used idioms? I think that the `on` function from > this proposal is the most widely used version of any other function with > the same name. When I see `on` in the code, I first expect the version from > `base`, not from some external library with a different type. Implementing > your own `on` in your library and forcing users to use it makes code hard > to read and reason about. Especially when people are using implicit imports > — good luck figuring out which one `on` is used! I believe that if `on` was > already imported by `Prelude`, fewer people would introduce identifiers > with this name. Which means that exporting `on` from `Prelude` is an > excellent thing to do if `Prelude` wants to force idiomatic usage of this > function. > > On Wed, Sep 11, 2019 at 1:53 AM David Feuer wrote: > >> Every time I reach for Data.Function.on, I feel like a total dolt for >> having to import a module to get a function whose implementation is barely >> longer than the import. And it's a really good function too! Can we please >> add it to the Prelude? >> >> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >> (.*.) `on` f = \x y -> f x .*. f y >> _______________________________________________ >> 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 eacameron at gmail.com Wed Sep 11 13:00:24 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 11 Sep 2019 09:00:24 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Perhaps this question should be answered: What is the guiding principle for Prelude? Why does it exist? This is probably the most contentious module in all of Haskell's ecosystem. Everyone wants to vie for their definition of "idiomatic" and getting something into Prelude is how you "win". But we all already have things in Prelude we don't like... Like head... How did that get in there? I'm sure many of us would love to go back and remove it. But once something is in Prelude it's "idiomatic" so becomes extremely hard to remove. So, What guides Prelude? Why does Prelude exist? If there's an answer to that in the report or something, I sense it would make these discussions so much simpler. If there is no answer then there is no metric by which to judge any comment in this thread. On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel wrote: > Hello everyone, > > To provide another data-point; in my "Prelude module replacement" package > > http://hackage.haskell.org/package/Prelude > > which encodes a common standard vocabulary from `base` I've observed in my > own projects over the years where I often keep a "local prelude" module for > the purpose of establishing a project-specific common vocabulary. Under > these constraints, `on` as well as `&` happens to be such a common > vocabulary which I expect to have in my default scope, and thus is > reexported from the "Prelude" module: > > http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21 > > But then again, since it's so easy to implement your own opinionated > "Prelude" replacement (either project-local or as a package on Hackage), > and subjective tastes differ greatly as the recent controversial > "singleton" proposal showed, and even though reexporting `on` from Prelude > has an objective merit in contrast, and I can definitely sympathise with > *this* proposal, I'm not sure if we really need to modify `base` to > achieve the stated goal of having a more convenient function in scope. > > But to be clear; at this point, I'm neither for nor against the proposal > to reexport names from Data.Function from the `base` Prelude. > > On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov > wrote: > >> +1 from me >> >> We export `on` from `relude` by default and didn't have any problems so >> far: >> >> * >> http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on >> >> I believe that this proposal hits the same wall like all other proposals >> regarding changes to the standard library — it's not clear, what are >> Prelude goals. Should it be minimal and provide only fundamental things, or >> should it enforce commonly used idioms? I think that the `on` function from >> this proposal is the most widely used version of any other function with >> the same name. When I see `on` in the code, I first expect the version from >> `base`, not from some external library with a different type. Implementing >> your own `on` in your library and forcing users to use it makes code hard >> to read and reason about. Especially when people are using implicit imports >> — good luck figuring out which one `on` is used! I believe that if `on` was >> already imported by `Prelude`, fewer people would introduce identifiers >> with this name. Which means that exporting `on` from `Prelude` is an >> excellent thing to do if `Prelude` wants to force idiomatic usage of this >> function. >> >> On Wed, Sep 11, 2019 at 1:53 AM David Feuer >> wrote: >> >>> Every time I reach for Data.Function.on, I feel like a total dolt for >>> having to import a module to get a function whose implementation is barely >>> longer than the import. And it's a really good function too! Can we please >>> add it to the Prelude? >>> >>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>> (.*.) `on` f = \x y -> f x .*. f y >>> _______________________________________________ >>> 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 ivan.miljenovic at gmail.com Wed Sep 11 14:11:16 2019 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 11 Sep 2019 22:11:16 +0800 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: -1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude). I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that. On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, wrote: > Perhaps this question should be answered: What is the guiding principle > for Prelude? Why does it exist? > > This is probably the most contentious module in all of Haskell's > ecosystem. Everyone wants to vie for their definition of "idiomatic" and > getting something into Prelude is how you "win". But we all already have > things in Prelude we don't like... Like head... How did that get in there? > I'm sure many of us would love to go back and remove it. But once something > is in Prelude it's "idiomatic" so becomes extremely hard to remove. > > So, What guides Prelude? Why does Prelude exist? > > If there's an answer to that in the report or something, I sense it would > make these discussions so much simpler. If there is no answer then there is > no metric by which to judge any comment in this thread. > > > On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel > wrote: > >> Hello everyone, >> >> To provide another data-point; in my "Prelude module replacement" package >> >> http://hackage.haskell.org/package/Prelude >> >> which encodes a common standard vocabulary from `base` I've observed in >> my own projects over the years where I often keep a "local prelude" module >> for the purpose of establishing a project-specific common vocabulary. Under >> these constraints, `on` as well as `&` happens to be such a common >> vocabulary which I expect to have in my default scope, and thus is >> reexported from the "Prelude" module: >> >> http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21 >> >> But then again, since it's so easy to implement your own opinionated >> "Prelude" replacement (either project-local or as a package on Hackage), >> and subjective tastes differ greatly as the recent controversial >> "singleton" proposal showed, and even though reexporting `on` from Prelude >> has an objective merit in contrast, and I can definitely sympathise with >> *this* proposal, I'm not sure if we really need to modify `base` to >> achieve the stated goal of having a more convenient function in scope. >> >> But to be clear; at this point, I'm neither for nor against the proposal >> to reexport names from Data.Function from the `base` Prelude. >> >> On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov >> wrote: >> >>> +1 from me >>> >>> We export `on` from `relude` by default and didn't have any problems so >>> far: >>> >>> * >>> http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on >>> >>> I believe that this proposal hits the same wall like all other proposals >>> regarding changes to the standard library — it's not clear, what are >>> Prelude goals. Should it be minimal and provide only fundamental things, or >>> should it enforce commonly used idioms? I think that the `on` function from >>> this proposal is the most widely used version of any other function with >>> the same name. When I see `on` in the code, I first expect the version from >>> `base`, not from some external library with a different type. Implementing >>> your own `on` in your library and forcing users to use it makes code hard >>> to read and reason about. Especially when people are using implicit imports >>> — good luck figuring out which one `on` is used! I believe that if `on` was >>> already imported by `Prelude`, fewer people would introduce identifiers >>> with this name. Which means that exporting `on` from `Prelude` is an >>> excellent thing to do if `Prelude` wants to force idiomatic usage of this >>> function. >>> >>> On Wed, Sep 11, 2019 at 1:53 AM David Feuer >>> wrote: >>> >>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>> having to import a module to get a function whose implementation is barely >>>> longer than the import. And it's a really good function too! Can we please >>>> add it to the Prelude? >>>> >>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>> (.*.) `on` f = \x y -> f x .*. f y >>>> _______________________________________________ >>>> 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 helmut.schmidt.4711 at gmail.com Wed Sep 11 14:32:34 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Wed, 11 Sep 2019 14:32:34 +0000 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: Taylor, Is it really necessary for you to be so rude? I can assure you that my proposal has been made in the same good faith as your proposal which inspired mine. Besides that unnecessary snark you do make an excellent point regarding the poor discoverability of the list constructor which I imagine must cause a lot of confusion among newcomers.Thank you for keeping an open mind! Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak : > I suspect this proposal was not made in good faith. I feel like it was > meant to make fun of my list singleton proposal. > > In spite of that, I am in favor of this proposal. One of the (very minor!) > problems with lists in Haskell is that they can’t be documented with > Haddock because they’re part of the syntax. For example, if you search > Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list > constructor. You will find `cons` from the `extra` package, which I think > suggests that this proposal is a good idea. > > +1 > > > On Sep 11, 2019, at 4:13 AM, Oliver Charles > wrote: > > > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > > wrote: > > > >> I can't be the only that wants this function, right? > > > > You're not the only one! I would also like this function. In fact, > > only yesterday I found myself writing > > > > ( x : ) <$> recurse xs > > > > I would have preferred > > > > cons x <$> recurse xs > > > > +1 to adding cons :: x -> [x] -> [x] to Data.List. > > > > Ollie > > _______________________________________________ > > 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 ollie at ocharles.org.uk Wed Sep 11 14:44:30 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 11 Sep 2019 15:44:30 +0100 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: -1, for the same reasons as Ivan. I would prefer *everything* to have an explicit import "binding site", and I'd also rather that not be a huge single line from one module (though of course, I can break the import up other multiple lines). On Wed, Sep 11, 2019 at 3:11 PM Ivan Lazar Miljenovic wrote: > > -1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude). > > I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that. > > On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, wrote: >> >> Perhaps this question should be answered: What is the guiding principle for Prelude? Why does it exist? >> >> This is probably the most contentious module in all of Haskell's ecosystem. Everyone wants to vie for their definition of "idiomatic" and getting something into Prelude is how you "win". But we all already have things in Prelude we don't like... Like head... How did that get in there? I'm sure many of us would love to go back and remove it. But once something is in Prelude it's "idiomatic" so becomes extremely hard to remove. >> >> So, What guides Prelude? Why does Prelude exist? >> >> If there's an answer to that in the report or something, I sense it would make these discussions so much simpler. If there is no answer then there is no metric by which to judge any comment in this thread. >> >> >> On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel wrote: >>> >>> Hello everyone, >>> >>> To provide another data-point; in my "Prelude module replacement" package >>> >>> http://hackage.haskell.org/package/Prelude >>> >>> which encodes a common standard vocabulary from `base` I've observed in my own projects over the years where I often keep a "local prelude" module for the purpose of establishing a project-specific common vocabulary. Under these constraints, `on` as well as `&` happens to be such a common vocabulary which I expect to have in my default scope, and thus is reexported from the "Prelude" module: >>> >>> http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21 >>> >>> But then again, since it's so easy to implement your own opinionated "Prelude" replacement (either project-local or as a package on Hackage), and subjective tastes differ greatly as the recent controversial "singleton" proposal showed, and even though reexporting `on` from Prelude has an objective merit in contrast, and I can definitely sympathise with *this* proposal, I'm not sure if we really need to modify `base` to achieve the stated goal of having a more convenient function in scope. >>> >>> But to be clear; at this point, I'm neither for nor against the proposal to reexport names from Data.Function from the `base` Prelude. >>> >>> On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov wrote: >>>> >>>> +1 from me >>>> >>>> We export `on` from `relude` by default and didn't have any problems so far: >>>> >>>> * http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on >>>> >>>> I believe that this proposal hits the same wall like all other proposals regarding changes to the standard library — it's not clear, what are Prelude goals. Should it be minimal and provide only fundamental things, or should it enforce commonly used idioms? I think that the `on` function from this proposal is the most widely used version of any other function with the same name. When I see `on` in the code, I first expect the version from `base`, not from some external library with a different type. Implementing your own `on` in your library and forcing users to use it makes code hard to read and reason about. Especially when people are using implicit imports — good luck figuring out which one `on` is used! I believe that if `on` was already imported by `Prelude`, fewer people would introduce identifiers with this name. Which means that exporting `on` from `Prelude` is an excellent thing to do if `Prelude` wants to force idiomatic usage of this function. >>>> >>>> On Wed, Sep 11, 2019 at 1:53 AM David Feuer wrote: >>>>> >>>>> Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function whose implementation is barely longer than the import. And it's a really good function too! Can we please add it to the Prelude? >>>>> >>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>> _______________________________________________ >>>>> 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 From helmut.schmidt.4711 at gmail.com Wed Sep 11 14:49:07 2019 From: helmut.schmidt.4711 at gmail.com (Helmut Schmidt) Date: Wed, 11 Sep 2019 14:49:07 +0000 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: What do you mean by "I'd also rather that not be a huge single line from one module"? Can you elaborate how this relates to the proposal? Am Mi., 11. Sept. 2019 um 14:45 Uhr schrieb Oliver Charles < ollie at ocharles.org.uk>: > I would prefer *everything* to have an explicit import "binding site", > and I'd also rather that not be a huge single line from one module > (though of course, I can break the import up other multiple lines). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Sep 11 15:21:14 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 11 Sep 2019 16:21:14 +0100 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: I would ignore that comment actually, it's not well thought out. (I was roughly meaning that I don't want to write `import Prelude (x1, x2, ..., x500)`, but this isn't a valid argument as I don't actually explicitly import `Prelude` anyway). That said, I would still prefer as many symbols as possible to have explicit binding sites, which means I would prefer to be explicit about my import to `on` rather than assume it from the Prelude. On Wed, Sep 11, 2019 at 3:49 PM Helmut Schmidt wrote: > > > What do you mean by "I'd also rather that not be a huge single line from one module"? Can you elaborate how this relates to the proposal? > > Am Mi., 11. Sept. 2019 um 14:45 Uhr schrieb Oliver Charles : >> >> I would prefer *everything* to have an explicit import "binding site", >> and I'd also rather that not be a huge single line from one module >> (though of course, I can break the import up other multiple lines). From targen at gmail.com Wed Sep 11 15:41:01 2019 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Wed, 11 Sep 2019 17:41:01 +0200 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Wed, Sep 11, 2019 at 5:21 PM Oliver Charles wrote: > That said, I would still prefer as many symbols as possible to have > explicit binding sites, which means I would prefer to be explicit > about my import to `on` rather than assume it from the Prelude. I personally share this preference. In my own code, I enable NoImplicitPrelude and explicitly import symbols from whatever module is the logical home for any given symbol. As I have this personal preference, I would explicitly `import Data.Function (on)` as I do today, irrespective of the outcome of this proposal. This is generally possible for any symbol that is not actually defined in the Prelude but merely re-exported from somewhere else. I mean to say that this particular style neither benefits nor is impaired much by this proposal. There would still be a Prelude with lots of symbols, and you will still be able to pretend there isn't one to the benefit of explicit binding sites, to whichever degree you personally favour. From qdunkan at gmail.com Wed Sep 11 16:20:24 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 11 Sep 2019 09:20:24 -0700 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Wed, Sep 11, 2019 at 7:11 AM Ivan Lazar Miljenovic wrote: > > -1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude). > > I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that. I solved the "not in prelude" problem for myself long ago by writing a tool to manage imports. So I either use a local "prelude addition" module, or I configure the tool with the set of things I'd like to be in scope unqualified and it makes sure they're imported if they're used. Not that I expect everyone to use such a tool, but just that there are a few ways to solve the problem. When the Prelude changes it becomes especially easy to break compatibility with a previous ghc version. Even if you have CI running with previous ghcs, the notification is very late. I suppose hlint could probably be configured to warn in advance though. To this day I still have lots of "unused import" warnings due to (<>) that I can't get rid of without either tons of CPP or dropping compatibility for whatever version it was that put it in prelude (though I think Monoid was worth it!). From lysxia at gmail.com Wed Sep 11 18:01:36 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Wed, 11 Sep 2019 14:01:36 -0400 Subject: Strict getContents Message-ID: Hello Libraries, In base, the functions which read all contents from a handle or file into one String currently all do lazy IO: readFile, getContents, hGetContents. https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGetContents The easiest way to get a strict alternative seems to be to explicitly force the list, for example using ```length contents `seq` pure ()```, but that's far from an obvious solution. Is there a better way? If not, I propose to add readFile', getContents', hGetContents', which don't do lazy IO. It regularly creates confusion among beginners, and it's easy to assume that lazy IO is benign if that's the only way to do certain operations, when it's arguably the wrong way to read files to begin with. Cheers, Li-yao From vamchale at gmail.com Wed Sep 11 18:36:04 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 11 Sep 2019 13:36:04 -0500 Subject: Strict getContents In-Reply-To: References: Message-ID: <56C7B96E-9228-4FA8-B0D6-B94D572C2A14@gmail.com> I believe such a function exists in the strict package. I agree that it would be good to add such functions to base. > On Sep 11, 2019, at 1:01 PM, Li-yao Xia wrote: > > Hello Libraries, > > In base, the functions which read all contents from a handle or file into one String currently all do lazy IO: readFile, getContents, hGetContents. > > https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGetContents > > The easiest way to get a strict alternative seems to be to explicitly force the list, for example using ```length contents `seq` pure ()```, but that's far from an obvious solution. > > Is there a better way? > > If not, I propose to add readFile', getContents', hGetContents', which don't do lazy IO. > > It regularly creates confusion among beginners, and it's easy to assume that lazy IO is benign if that's the only way to do certain operations, when it's arguably the wrong way to read files to begin with. > > Cheers, > Li-yao > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From lemming at henning-thielemann.de Wed Sep 11 18:52:35 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Sep 2019 20:52:35 +0200 (CEST) Subject: Strict getContents In-Reply-To: References: Message-ID: On Wed, 11 Sep 2019, Li-yao Xia wrote: > The easiest way to get a strict alternative seems to be to explicitly > force the list, for example using ```length contents `seq` pure ()```, > but that's far from an obvious solution. I am not sure, whether this works reliably. Evaluating the length of 'contents' only generates the skeleton of the list but not immediately the element values. A cleaner way would be to use 'deepseq'. From lysxia at gmail.com Wed Sep 11 20:13:30 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Wed, 11 Sep 2019 16:13:30 -0400 Subject: Strict getContents In-Reply-To: References: Message-ID: <6e5d40f5-4c21-321c-06b3-2d4701267569@gmail.com> Hi Henning, On 9/11/19 2:52 PM, Henning Thielemann wrote: > > On Wed, 11 Sep 2019, Li-yao Xia wrote: > >> The easiest way to get a strict alternative seems to be to explicitly >> force the list, for example using ```length contents `seq` pure ()```, >> but that's far from an obvious solution. > > I am not sure, whether this works reliably. Evaluating the length of > 'contents' only generates the skeleton of the list but not immediately > the element values. A cleaner way would be to use 'deepseq'. That's an interesting question, because I'm pretty confident this is a reliable way to force getContents, but I'm less sure I can convince you of it easily. Thinking of how that could break, I believe that one would have to get out of their way in order to implement getContents such that forcing the list does not also make its characters available even after the file is closed, at which point the author of that function should stop and wonder whether it is worth the trouble, and I trust that the author, if they even considered the possibility, would reach the reasonable conclusion of "don't do that". Of course, that argument can go wrong in many ways, especially because it is full of subjective judgements. So to get some closure, let's look at the source code. Skipping over the intermediate steps that one would have to check for themselves anyway, it boils down to this unpack function: https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Handle.Text.html#unpack Near the end of the function is the line that adds a character c as part of the string that will be returned at the end, we can see that the cons comes with the character fully read by peekElemOf: unpackRB (c : acc) (i-1) Cheers, Li-yao From vamchale at gmail.com Wed Sep 11 20:19:56 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 11 Sep 2019 20:19:56 +0000 Subject: Strict getContents In-Reply-To: <6e5d40f5-4c21-321c-06b3-2d4701267569@gmail.com> References: <6e5d40f5-4c21-321c-06b3-2d4701267569@gmail.com> Message-ID: <215fcb7c-5320-694b-4fdc-b7676f7ddd77@gmail.com> Wouldn't it be more sensible to not interleave IO in the first place? Cheers, Vanessa On 9/11/19 8:13 PM, Li-yao Xia wrote: > Hi Henning, > > > On 9/11/19 2:52 PM, Henning Thielemann wrote: > > > > On Wed, 11 Sep 2019, Li-yao Xia wrote: > > > >> The easiest way to get a strict alternative seems to be to explicitly > >> force the list, for example using ```length contents `seq` pure ()```, > >> but that's far from an obvious solution. > > > > I am not sure, whether this works reliably. Evaluating the length of > > 'contents' only generates the skeleton of the list but not immediately > > the element values. A cleaner way would be to use 'deepseq'. > > > That's an interesting question, because I'm pretty confident this is a > reliable way to force getContents, but I'm less sure I can convince > you of it easily. > > Thinking of how that could break, I believe that one would have to get > out of their way in order to implement getContents such that forcing > the list does not also make its characters available even after the > file is closed, at which point the author of that function should stop > and wonder whether it is worth the trouble, and I trust that the > author, if they even considered the possibility, would reach the > reasonable conclusion of "don't do that". > > Of course, that argument can go wrong in many ways, especially because > it is full of subjective judgements. So to get some closure, let's > look at the source code. Skipping over the intermediate steps that one > would have to check for themselves anyway, it boils down to this > unpack function: > > https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Handle.Text.html#unpack > > > Near the end of the function is the line that adds a character c as > part of the string that will be returned at the end, we can see that > the cons comes with the character fully read by peekElemOf: > >               unpackRB (c : acc) (i-1) > > Cheers, > Li-yao > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From lexi.lambda at gmail.com Wed Sep 11 22:35:07 2019 From: lexi.lambda at gmail.com (Alexis King) Date: Wed, 11 Sep 2019 17:35:07 -0500 Subject: Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics In-Reply-To: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> References: <78E9895C-AD07-44FB-BB21-ABE87E6D4395@gmail.com> Message-ID: <945FE644-10BD-494D-9A49-0C9AA52D24B2@gmail.com> As just one more data point, Rob Rix from the GitHub semantic code team has pointed out to me that their `semantic` library also includes a `Generically1` type, defined here: https://github.com/github/semantic/blob/8c0041f1ec5a3ee9f3d0294c35220bfde209c68b/src/Data/Functor/Classes/Generic.hs#L184-L190 (They call it `Generically`, but it’s actually equivalent to the `Generically1` type from `generic-data` and serves the same purpose.) From josephcsible at gmail.com Wed Sep 11 22:56:55 2019 From: josephcsible at gmail.com (Joseph C. Sible) Date: Wed, 11 Sep 2019 18:56:55 -0400 Subject: Strict getContents In-Reply-To: References: Message-ID: +1 to adding those non-lazy versions. Such functions could work without having to half-close the handle, thus making it easier to continue reading from a file after EOF (à la `tail -f`). (I've asked about how to do this exact thing before at https://stackoverflow.com/q/56221606/7509065 and this would give it a trivial answer.) Joseph C. Sible On Wed, Sep 11, 2019 at 2:01 PM Li-yao Xia wrote: > > Hello Libraries, > > In base, the functions which read all contents from a handle or file > into one String currently all do lazy IO: readFile, getContents, > hGetContents. > > https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGetContents > > The easiest way to get a strict alternative seems to be to explicitly > force the list, for example using ```length contents `seq` pure ()```, > but that's far from an obvious solution. > > Is there a better way? > > If not, I propose to add readFile', getContents', hGetContents', which > don't do lazy IO. > > It regularly creates confusion among beginners, and it's easy to assume > that lazy IO is benign if that's the only way to do certain operations, > when it's arguably the wrong way to read files to begin with. > > Cheers, > Li-yao > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From emertens at gmail.com Thu Sep 12 02:41:49 2019 From: emertens at gmail.com (Eric Mertens) Date: Wed, 11 Sep 2019 19:41:49 -0700 Subject: Strict getContents In-Reply-To: References: Message-ID: I like the idea of having strict versions of these functions. I also prefer to recommend people use the strict versions of these functions from text package's Data.Text.IO to encouraging using String to load files. I agree that people should be able to read file contents strictly without having to use tricks like forcing the length. On Wed, Sep 11, 2019 at 3:57 PM Joseph C. Sible wrote: > +1 to adding those non-lazy versions. Such functions could work > without having to half-close the handle, thus making it easier to > continue reading from a file after EOF (à la `tail -f`). (I've asked > about how to do this exact thing before at > https://stackoverflow.com/q/56221606/7509065 and this would give it a > trivial answer.) > > Joseph C. Sible > > On Wed, Sep 11, 2019 at 2:01 PM Li-yao Xia wrote: > > > > Hello Libraries, > > > > In base, the functions which read all contents from a handle or file > > into one String currently all do lazy IO: readFile, getContents, > > hGetContents. > > > > > https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGetContents > > > > The easiest way to get a strict alternative seems to be to explicitly > > force the list, for example using ```length contents `seq` pure ()```, > > but that's far from an obvious solution. > > > > Is there a better way? > > > > If not, I propose to add readFile', getContents', hGetContents', which > > don't do lazy IO. > > > > It regularly creates confusion among beginners, and it's easy to assume > > that lazy IO is benign if that's the only way to do certain operations, > > when it's arguably the wrong way to read files to begin with. > > > > Cheers, > > Li-yao > > _______________________________________________ > > 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 > -- Eric Mertens -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Thu Sep 12 14:42:31 2019 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 12 Sep 2019 16:42:31 +0200 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: I think this proposal was be stronger if it would lay out the bigger picture, i.e., directions towards a unified interface to sequence-like collections. -1 in its current form. On 2019-09-11 16:32, Helmut Schmidt wrote: > Taylor, > > Is it really necessary for you to be so rude? I can assure you that my > proposal has been made in the same good faith as your proposal which > inspired mine. > > Besides that unnecessary snark you do make an excellent point regarding > the poor discoverability of the list constructor which I imagine must > cause a lot of confusion among newcomers.Thank you for keeping an open mind! > > > > Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak > >: > > I suspect this proposal was not made in good faith. I feel like it > was meant to make fun of my list singleton proposal. > > In spite of that, I am in favor of this proposal. One of the (very > minor!) problems with lists in Haskell is that they can’t be > documented with Haddock because they’re part of the syntax. For > example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you > won’t find the venerable list constructor. You will find `cons` from > the `extra` package, which I think suggests that this proposal is a > good idea. > > +1 > > > On Sep 11, 2019, at 4:13 AM, Oliver Charles > > wrote: > > > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > > > wrote: > > > >> I can't be the only that wants this function, right? > > > > You're not the only one! I would also like this function. In fact, > > only yesterday I found myself writing > > > >  ( x : ) <$> recurse xs > > > > I would have preferred > > > >  cons x <$> recurse xs > > > > +1 to adding  cons :: x -> [x] -> [x]  to  Data.List. > > > > Ollie > > _______________________________________________ > > 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 andreas.abel at ifi.lmu.de Thu Sep 12 14:48:50 2019 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 12 Sep 2019 16:48:50 +0200 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: <38797e84-3421-ca8b-e606-1f4f1b9ed2bb@ifi.lmu.de> +1 for adding `on` to the Prelude. On 2019-09-11 00:59, David Feuer wrote: > Indeed, there are a lot more conflicts than I'd have expected. Ignoring > functions with the same type, Hoogle shows this name in the below > packages. I have no sense of the overall significance of the specific > packages or (equally importantly) of the `on` function within each. > > haskell-gi-base: > on :: forall object info m . (GObject object, MonadIO m, SignalInfo > info) => object -> SignalProxy object info -> HaskellCallbackType info > -> m SignalHandlerId > > brick: > on :: Color -> Color -> Attr > > esqueletto: > on :: SqlExpr (Value Bool) -> SqlQuery () > > relational-query (both): > on :: MonadQuery m => Predicate Flat -> m () > on :: MonadQuery m => QueryA m (Predicate Flat) () > > threepenny-gui: > on :: (element -> Event a) -> element -> (a -> UI void) -> UI () > > miso: > on :: MisoString -> Decoder r -> (r -> action) -> Attribute action > > wild-bind: > on :: i -> v -> Binder i v () > > massiv-io: > on :: Pixel X Bit > > selda-postgresql: > on :: Text -> Text -> PGConnectInfo > > > On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle > wrote: > > One note: this does conflict with some other libraries, for instance > GTK2HS > > On Tue, Sep 10, 2019 at 6:26 PM chessai . > wrote: > > +1 > > On Tue, Sep 10, 2019, 5:53 PM David Feuer > wrote: > > Every time I reach for Data.Function.on, I feel like a total > dolt for having to import a module to get a function whose > implementation is barely longer than the import. And it's a > really good function too! Can we please add it to the Prelude? > >   on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >   (.*.) `on` f = \x y -> f x .*. f y > _______________________________________________ > 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 david.feuer at gmail.com Thu Sep 12 14:51:20 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Sep 2019 10:51:20 -0400 Subject: Strict getContents In-Reply-To: References: Message-ID: Certainly reading directly into a String is inefficient for a strict read. I imagine the best way is to read (eagerly) into a lazy ByteString and decode that lazily into a String. Even for Text, it may well be better to read into a lazy ByteString and decode into lazy Text, since the latter tends to take considerably more memory. On Wed, Sep 11, 2019, 2:01 PM Li-yao Xia wrote: > Hello Libraries, > > In base, the functions which read all contents from a handle or file > into one String currently all do lazy IO: readFile, getContents, > hGetContents. > > > https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGetContents > > The easiest way to get a strict alternative seems to be to explicitly > force the list, for example using ```length contents `seq` pure ()```, > but that's far from an obvious solution. > > Is there a better way? > > If not, I propose to add readFile', getContents', hGetContents', which > don't do lazy IO. > > It regularly creates confusion among beginners, and it's easy to assume > that lazy IO is benign if that's the only way to do certain operations, > when it's arguably the wrong way to read files to begin with. > > Cheers, > Li-yao > _______________________________________________ > 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 Thu Sep 12 14:54:41 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Sep 2019 10:54:41 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Describing another's proposal as "pointless" contributes to the perception that this is an unfriendly community. Please don't do that! If you want to explain why you think Proposal X is more worthy than Proposal Y, you should do so constructively and sensitively. On Tue, Sep 10, 2019, 6:42 PM Helmut Schmidt wrote: > > Am Di., 10. Sept. 2019 um 21:53 Uhr schrieb David Feuer < > david.feuer at gmail.com>: > >> Every time I reach for Data.Function.on, I feel like a total dolt for >> having to import a module to get a function whose implementation is barely >> longer than the import. And it's a really good function too! Can we please >> add it to the Prelude? >> > > Agreed. This function makes only sense to have if the cost of getting it > into scope doesn't outweigh its benefit and therefore I support this > proposal which makes a lot more sense than the pointless singleton proposal. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Sep 12 14:55:09 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Sep 2019 10:55:09 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: For whatever it's worth, the unidiomatic but arguably more logical name `on2` has no hits on Hoogle. On Tue, Sep 10, 2019, 6:59 PM David Feuer wrote: > Indeed, there are a lot more conflicts than I'd have expected. Ignoring > functions with the same type, Hoogle shows this name in the below packages. > I have no sense of the overall significance of the specific packages or > (equally importantly) of the `on` function within each. > > haskell-gi-base: > on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) > => object -> SignalProxy object info -> HaskellCallbackType info -> m > SignalHandlerId > > brick: > on :: Color -> Color -> Attr > > esqueletto: > on :: SqlExpr (Value Bool) -> SqlQuery () > > relational-query (both): > on :: MonadQuery m => Predicate Flat -> m () > on :: MonadQuery m => QueryA m (Predicate Flat) () > > threepenny-gui: > on :: (element -> Event a) -> element -> (a -> UI void) -> UI () > > miso: > on :: MisoString -> Decoder r -> (r -> action) -> Attribute action > > wild-bind: > on :: i -> v -> Binder i v () > > massiv-io: > on :: Pixel X Bit > > selda-postgresql: > on :: Text -> Text -> PGConnectInfo > > > On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle wrote: > >> One note: this does conflict with some other libraries, for instance >> GTK2HS >> >> On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: >> >>> +1 >>> >>> On Tue, Sep 10, 2019, 5:53 PM David Feuer wrote: >>> >>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>> having to import a module to get a function whose implementation is barely >>>> longer than the import. And it's a really good function too! Can we please >>>> add it to the Prelude? >>>> >>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>> (.*.) `on` f = \x y -> f x .*. f y >>>> _______________________________________________ >>>> 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 eacameron at gmail.com Thu Sep 12 14:57:06 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Thu, 12 Sep 2019 10:57:06 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: You might be on2 something. But then you rename it in Data.Function too and break backward compat?? On Thu, Sep 12, 2019 at 10:55 AM David Feuer wrote: > For whatever it's worth, the unidiomatic but arguably more logical name > `on2` has no hits on Hoogle. > > On Tue, Sep 10, 2019, 6:59 PM David Feuer wrote: > >> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >> functions with the same type, Hoogle shows this name in the below packages. >> I have no sense of the overall significance of the specific packages or >> (equally importantly) of the `on` function within each. >> >> haskell-gi-base: >> on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) >> => object -> SignalProxy object info -> HaskellCallbackType info -> m >> SignalHandlerId >> >> brick: >> on :: Color -> Color -> Attr >> >> esqueletto: >> on :: SqlExpr (Value Bool) -> SqlQuery () >> >> relational-query (both): >> on :: MonadQuery m => Predicate Flat -> m () >> on :: MonadQuery m => QueryA m (Predicate Flat) () >> >> threepenny-gui: >> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >> >> miso: >> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >> >> wild-bind: >> on :: i -> v -> Binder i v () >> >> massiv-io: >> on :: Pixel X Bit >> >> selda-postgresql: >> on :: Text -> Text -> PGConnectInfo >> >> >> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >> wrote: >> >>> One note: this does conflict with some other libraries, for instance >>> GTK2HS >>> >>> On Tue, Sep 10, 2019 at 6:26 PM chessai . wrote: >>> >>>> +1 >>>> >>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>> wrote: >>>> >>>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>>> having to import a module to get a function whose implementation is barely >>>>> longer than the import. And it's a really good function too! Can we please >>>>> add it to the Prelude? >>>>> >>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>> _______________________________________________ >>>>> 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 b at chreekat.net Thu Sep 12 15:05:05 2019 From: b at chreekat.net (Bryan Richter) Date: Thu, 12 Sep 2019 18:05:05 +0300 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: I had the same reaction as Taylor, since Helmut referred to the singleton proposal as "pointless" in the thread on "on". Then I stopped to wonder if there was a mixup. "Point-free" style, which cons and singleton both facilitate, is sometimes called "pointless" style, but usually only as a joke. It's wordplay. Since Helmut writes perfectly good English, I had assumed the wordplay was intentional, which made me suspicious of the nature of this proposal. But from over here on my little digital device, it is hard to know for sure. Either way, I think the plan to make Data.List qualified-by-default is great, and having a uniform abstraction over list-like things is also good. I look forward to seeing more use of backpack to take advantage of such abstractions. I suggest that the haddocks for Data.List.cons clearly state that it is just a synonym for the list constructor, so we get a built-in "teachable moment". On Wed, 11 Sep 2019, 17.33 Helmut Schmidt, wrote: > Taylor, > > Is it really necessary for you to be so rude? I can assure you that my > proposal has been made in the same good faith as your proposal which > inspired mine. > > Besides that unnecessary snark you do make an excellent point regarding > the poor discoverability of the list constructor which I imagine must cause > a lot of confusion among newcomers.Thank you for keeping an open mind! > > > > Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak < > taylor at fausak.me>: > >> I suspect this proposal was not made in good faith. I feel like it was >> meant to make fun of my list singleton proposal. >> >> In spite of that, I am in favor of this proposal. One of the (very >> minor!) problems with lists in Haskell is that they can’t be documented >> with Haddock because they’re part of the syntax. For example, if you search >> Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list >> constructor. You will find `cons` from the `extra` package, which I think >> suggests that this proposal is a good idea. >> >> +1 >> >> > On Sep 11, 2019, at 4:13 AM, Oliver Charles >> wrote: >> > >> > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt >> > wrote: >> > >> >> I can't be the only that wants this function, right? >> > >> > You're not the only one! I would also like this function. In fact, >> > only yesterday I found myself writing >> > >> > ( x : ) <$> recurse xs >> > >> > I would have preferred >> > >> > cons x <$> recurse xs >> > >> > +1 to adding cons :: x -> [x] -> [x] to Data.List. >> > >> > Ollie >> > _______________________________________________ >> > 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 david.feuer at gmail.com Thu Sep 12 15:13:21 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Sep 2019 11:13:21 -0400 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: I think Michael Snoyman did a good job of starting that conversation with his IsSequence class in mono-traversable. I don't agree with a lot of the specific design decisions he's made, but I think we should definitely think about previous experience in that space. Personally, I prefer an MPTC-based interface for the monomorphic stuff. This is mostly a matter of taste, of course. One important idea, of course, is that of a free monoid: type family Elem xs class e ~ Elem c => MonoFoldable e c where mfoldMap :: Monoid m => (e -> m) -> c -> m class (MonoFoldable e c, Monoid c) => MonoSequence e c where mSingleton :: e -> c -- All other methods can be optional class (forall e. Monoid (t e)) => Monoid1 t instance (forall e. Monoid (t e)) => Monoid1 t class (Traversable t, Monoid1 t) => Sequence t where singleton :: e -> t e -- All other methods can be optional On Thu, Sep 12, 2019, 10:42 AM Andreas Abel wrote: > I think this proposal was be stronger if it would lay out the bigger > picture, i.e., directions towards a unified interface to sequence-like > collections. > > -1 in its current form. > > On 2019-09-11 16:32, Helmut Schmidt wrote: > > Taylor, > > > > Is it really necessary for you to be so rude? I can assure you that my > > proposal has been made in the same good faith as your proposal which > > inspired mine. > > > > Besides that unnecessary snark you do make an excellent point regarding > > the poor discoverability of the list constructor which I imagine must > > cause a lot of confusion among newcomers.Thank you for keeping an open > mind! > > > > > > > > Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak > > >: > > > > I suspect this proposal was not made in good faith. I feel like it > > was meant to make fun of my list singleton proposal. > > > > In spite of that, I am in favor of this proposal. One of the (very > > minor!) problems with lists in Haskell is that they can’t be > > documented with Haddock because they’re part of the syntax. For > > example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you > > won’t find the venerable list constructor. You will find `cons` from > > the `extra` package, which I think suggests that this proposal is a > > good idea. > > > > +1 > > > > > On Sep 11, 2019, at 4:13 AM, Oliver Charles > > > wrote: > > > > > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > > > > > wrote: > > > > > >> I can't be the only that wants this function, right? > > > > > > You're not the only one! I would also like this function. In fact, > > > only yesterday I found myself writing > > > > > > ( x : ) <$> recurse xs > > > > > > I would have preferred > > > > > > cons x <$> recurse xs > > > > > > +1 to adding cons :: x -> [x] -> [x] to Data.List. > > > > > > Ollie > > > _______________________________________________ > > > 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 david.feuer at gmail.com Thu Sep 12 15:15:13 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Sep 2019 11:15:13 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: No, there's certainly no need to remove the existing function. On Thu, Sep 12, 2019, 10:57 AM Elliot Cameron wrote: > You might be on2 something. > > But then you rename it in Data.Function too and break backward compat?? > > On Thu, Sep 12, 2019 at 10:55 AM David Feuer > wrote: > >> For whatever it's worth, the unidiomatic but arguably more logical name >> `on2` has no hits on Hoogle. >> >> On Tue, Sep 10, 2019, 6:59 PM David Feuer wrote: >> >>> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >>> functions with the same type, Hoogle shows this name in the below packages. >>> I have no sense of the overall significance of the specific packages or >>> (equally importantly) of the `on` function within each. >>> >>> haskell-gi-base: >>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>> SignalHandlerId >>> >>> brick: >>> on :: Color -> Color -> Attr >>> >>> esqueletto: >>> on :: SqlExpr (Value Bool) -> SqlQuery () >>> >>> relational-query (both): >>> on :: MonadQuery m => Predicate Flat -> m () >>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>> >>> threepenny-gui: >>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>> >>> miso: >>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>> >>> wild-bind: >>> on :: i -> v -> Binder i v () >>> >>> massiv-io: >>> on :: Pixel X Bit >>> >>> selda-postgresql: >>> on :: Text -> Text -> PGConnectInfo >>> >>> >>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>> wrote: >>> >>>> One note: this does conflict with some other libraries, for instance >>>> GTK2HS >>>> >>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>> wrote: >>>>> >>>>>> Every time I reach for Data.Function.on, I feel like a total dolt for >>>>>> having to import a module to get a function whose implementation is barely >>>>>> longer than the import. And it's a really good function too! Can we please >>>>>> add it to the Prelude? >>>>>> >>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>> _______________________________________________ >>>>>> 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 eacameron at gmail.com Thu Sep 12 15:19:32 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Thu, 12 Sep 2019 11:19:32 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: Bleh. Now we have two functions that do the same thing, both in base... I don't want "on" in prelude but this seems far worse to me than the original proposal. Let's stick with that one for now and if it dies you can propose this separately? :D On Thu, Sep 12, 2019 at 11:15 AM David Feuer wrote: > No, there's certainly no need to remove the existing function. > > On Thu, Sep 12, 2019, 10:57 AM Elliot Cameron wrote: > >> You might be on2 something. >> >> But then you rename it in Data.Function too and break backward compat?? >> >> On Thu, Sep 12, 2019 at 10:55 AM David Feuer >> wrote: >> >>> For whatever it's worth, the unidiomatic but arguably more logical name >>> `on2` has no hits on Hoogle. >>> >>> On Tue, Sep 10, 2019, 6:59 PM David Feuer wrote: >>> >>>> Indeed, there are a lot more conflicts than I'd have expected. Ignoring >>>> functions with the same type, Hoogle shows this name in the below packages. >>>> I have no sense of the overall significance of the specific packages or >>>> (equally importantly) of the `on` function within each. >>>> >>>> haskell-gi-base: >>>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>>> SignalHandlerId >>>> >>>> brick: >>>> on :: Color -> Color -> Attr >>>> >>>> esqueletto: >>>> on :: SqlExpr (Value Bool) -> SqlQuery () >>>> >>>> relational-query (both): >>>> on :: MonadQuery m => Predicate Flat -> m () >>>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>>> >>>> threepenny-gui: >>>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>>> >>>> miso: >>>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>>> >>>> wild-bind: >>>> on :: i -> v -> Binder i v () >>>> >>>> massiv-io: >>>> on :: Pixel X Bit >>>> >>>> selda-postgresql: >>>> on :: Text -> Text -> PGConnectInfo >>>> >>>> >>>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>>> wrote: >>>> >>>>> One note: this does conflict with some other libraries, for instance >>>>> GTK2HS >>>>> >>>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>>> wrote: >>>>>> >>>>>>> Every time I reach for Data.Function.on, I feel like a total dolt >>>>>>> for having to import a module to get a function whose implementation is >>>>>>> barely longer than the import. And it's a really good function too! Can we >>>>>>> please add it to the Prelude? >>>>>>> >>>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>>> _______________________________________________ >>>>>>> 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 yom at artyom.me Thu Sep 12 15:42:40 2019 From: yom at artyom.me (Artyom Kazak) Date: Thu, 12 Sep 2019 18:42:40 +0300 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: I don't use `on` because my usecases are covered by `sortOn` and `groupWith`; I can only recall a couple of cases when I had to resort to `on`, and I don't often see it in others' code either, or if I do it's often in conjuction with `sort` anyway. I have, however, seen people use `on` because it's /cute/, and it's definitely not something I would want to encourage. On the other hand, `for` and `when` and `and` and other common words are taken already and it almost never creates any problems for me, so I would not mind having `on` stolen either. So, I'm -0.5 on the proposal. On Thu, Sep 12, 2019, 18:20 Elliot Cameron wrote: > Bleh. Now we have two functions that do the same thing, both in base... I > don't want "on" in prelude but this seems far worse to me than the original > proposal. Let's stick with that one for now and if it dies you can propose > this separately? :D > > On Thu, Sep 12, 2019 at 11:15 AM David Feuer > wrote: > >> No, there's certainly no need to remove the existing function. >> >> On Thu, Sep 12, 2019, 10:57 AM Elliot Cameron >> wrote: >> >>> You might be on2 something. >>> >>> But then you rename it in Data.Function too and break backward compat?? >>> >>> On Thu, Sep 12, 2019 at 10:55 AM David Feuer >>> wrote: >>> >>>> For whatever it's worth, the unidiomatic but arguably more logical name >>>> `on2` has no hits on Hoogle. >>>> >>>> On Tue, Sep 10, 2019, 6:59 PM David Feuer >>>> wrote: >>>> >>>>> Indeed, there are a lot more conflicts than I'd have expected. >>>>> Ignoring functions with the same type, Hoogle shows this name in the below >>>>> packages. I have no sense of the overall significance of the specific >>>>> packages or (equally importantly) of the `on` function within each. >>>>> >>>>> haskell-gi-base: >>>>> on :: forall object info m . (GObject object, MonadIO m, SignalInfo >>>>> info) => object -> SignalProxy object info -> HaskellCallbackType info -> m >>>>> SignalHandlerId >>>>> >>>>> brick: >>>>> on :: Color -> Color -> Attr >>>>> >>>>> esqueletto: >>>>> on :: SqlExpr (Value Bool) -> SqlQuery () >>>>> >>>>> relational-query (both): >>>>> on :: MonadQuery m => Predicate Flat -> m () >>>>> on :: MonadQuery m => QueryA m (Predicate Flat) () >>>>> >>>>> threepenny-gui: >>>>> on :: (element -> Event a) -> element -> (a -> UI void) -> UI () >>>>> >>>>> miso: >>>>> on :: MisoString -> Decoder r -> (r -> action) -> Attribute action >>>>> >>>>> wild-bind: >>>>> on :: i -> v -> Binder i v () >>>>> >>>>> massiv-io: >>>>> on :: Pixel X Bit >>>>> >>>>> selda-postgresql: >>>>> on :: Text -> Text -> PGConnectInfo >>>>> >>>>> >>>>> On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle >>>>> wrote: >>>>> >>>>>> One note: this does conflict with some other libraries, for instance >>>>>> GTK2HS >>>>>> >>>>>> On Tue, Sep 10, 2019 at 6:26 PM chessai . >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer >>>>>>> wrote: >>>>>>> >>>>>>>> Every time I reach for Data.Function.on, I feel like a total dolt >>>>>>>> for having to import a module to get a function whose implementation is >>>>>>>> barely longer than the import. And it's a really good function too! Can we >>>>>>>> please add it to the Prelude? >>>>>>>> >>>>>>>> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>>>>>>> (.*.) `on` f = \x y -> f x .*. f y >>>>>>>> _______________________________________________ >>>>>>>> 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 andreas.abel at ifi.lmu.de Thu Sep 12 17:02:08 2019 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 12 Sep 2019 19:02:08 +0200 Subject: Incremental Regex Parsing with Fixed Strings In-Reply-To: References: Message-ID: <6dc45a56-e7ec-59ad-cf1c-e57a86e742b9@ifi.lmu.de> Andrew, The translation Regex -> NFA is compositional, thus, you could cache the NFAs computed for subregexs, only needing to recompute the NFA along the path to the changes subregex. Compilation to DFAs is not needed as you can use NFAs directly to recognize strings. --Andreas On 2019-03-01 17:06, Andrew Martin wrote: > Thank you so much for pointing me to this paper. What an absolute gem it > is! Efficiently evaluating regex with a recursive ADT instead of a graph > puts me one step closer to a solution. In my problem domain, regex > frequently are mostly sequences at the top level. That is, these are common: > >     The number [0-9]* is a good number >     I have [0-9]* pupp(ies|y). > > This are not: > >     (Hello|from|the|other|side)* > > Using the paper's terminology, I think I should be able to have a > `FingerTree X REG` (for some X I'm not sure of), where every top-level > sequence is represented as adjacent elements in the finger tree. I'm not > sure if this will actually work, but it seems plausible that it will. > > On Fri, Mar 1, 2019 at 3:55 AM Sergey Vinokurov > wrote: > > Modifying regular expressions reminds me of the great functional pearl > called 'A Play on Regular Expressions'. Perhaps this is the approach you > were thinking about? > > Sergey > > On 28/02/2019 18:43, Andrew Martin wrote: > > Greetings, > > > > In Dan Piponi's blog post Fast Incremental Regular Expression > Matching > > with Monoids [1], he outlines a way to take advantage of > fingertrees to > > perform increment regex matching. In his article, the regular > expression > > (more accurately, its equivalent DFA) is fixed, and the strings > we are > > matching on are modified incrementally. What I'm interested in is the > > opposite: What if the regular expression is modified > incrementally and > > the string we are testing is static? > > > > Thinking about this, it seems to run into problems immediately. > > Typically, to evaluate a regular expression, I would convert it > to a NFA > > (and then maybe to a DFA). But there is no way to do incremental > graph > > modification on the resulting graphs. (Or is there?). And even if > there > > were a way, it seems unclear how one would go about exploiting its > > incremental nature. To provide an example, consider the following > regex > > and sample string: > > > > Regex: Lost (dog|cat) loo for home > > Sample: Lost dog looking for home > > > > In the regex, I'm currently in the middle of typing "looking", so it > > doesn't match the sample string. But large parts of it do. So when I > > update the regex by typing "k", I'd like to be able to not redo this > > work. Maybe there's a certain subset of regex that's amenable to this > > kind of incremental evaluation. Maybe not. If anyone has any > additional > > insights or can point me to any research, I would appreciate it > greatly. > > Thanks. > > > > [1] > http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html > > > > > > -- > > -Andrew Thaddeus Martin > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > -- > -Andrew Thaddeus Martin > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From lemming at henning-thielemann.de Fri Sep 13 11:40:01 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 13 Sep 2019 13:40:01 +0200 (CEST) Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Tue, 10 Sep 2019, Elliot Cameron wrote: > We should all be making project-specific Preludes instead IMO. +1 From lemming at henning-thielemann.de Fri Sep 13 11:48:43 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 13 Sep 2019 13:48:43 +0200 (CEST) Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Tue, 10 Sep 2019, David Feuer wrote: > Indeed, there are a lot more conflicts than I'd have expected. Ignoring > functions with the same type, Hoogle shows this name in the below > packages. It's not only about top-level functions named 'on'. If I use 'on' as a local variable, then I get warnings about local redefinitions of the global Prelude.on. From lemming at henning-thielemann.de Fri Sep 13 11:53:55 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 13 Sep 2019 13:53:55 +0200 (CEST) Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Tue, 10 Sep 2019, David Feuer wrote: > Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function > whose implementation is barely longer than the import. And it's a really good function too! Can we please add it > to the Prelude? >   on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >   (.*.) `on` f = \x y -> f x .*. f y Most of the time I would use this I can use the more specific 'equating' and 'comparing'. I remember there was a lengthy discussion about the right name of 'on' and adding it to Data.Function. I had no need for that function because at this point I already had: https://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Function-HT.html#v:compose2 If I am right the short name 'on' was only adopted because it was not (automatically) exported by Prelude. From eacameron at gmail.com Fri Sep 13 13:32:45 2019 From: eacameron at gmail.com (Elliot Cameron) Date: Fri, 13 Sep 2019 09:32:45 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: > It's not only about top-level functions named 'on'. If I use 'on' as a local variable, then I get warnings about local redefinitions of the global Prelude.on. Oh heavens how did we not think of this point immediately? This frankly has me terrified of this proposal. This is such a cute name it's hard to imagine that it's not a local binding in numerous, invisible places. (Just last week I had to fix a package not on Hackage because it locally defined (<>)...) On Fri, Sep 13, 2019, 7:54 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Tue, 10 Sep 2019, David Feuer wrote: > > > Every time I reach for Data.Function.on, I feel like a total dolt for > having to import a module to get a function > > whose implementation is barely longer than the import. And it's a really > good function too! Can we please add it > > to the Prelude? > > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c > > (.*.) `on` f = \x y -> f x .*. f y > > Most of the time I would use this I can use the more specific 'equating' > and 'comparing'. > > I remember there was a lengthy discussion about the right name of 'on' and > adding it to Data.Function. I had no need for that function because at > this point I already had: > > https://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Function-HT.html#v:compose2 > > If I am right the short name 'on' was only adopted because it was not > (automatically) exported by > Prelude._______________________________________________ > 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 Sat Sep 14 02:14:19 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 13 Sep 2019 22:14:19 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: yeah, that pushes it to a hard -1 for me. On Fri, Sep 13, 2019 at 9:33 AM Elliot Cameron wrote: > > It's not only about top-level functions named 'on'. If I use 'on' as a > local variable, then I get warnings about local redefinitions of the > global Prelude.on. > > Oh heavens how did we not think of this point immediately? This frankly > has me terrified of this proposal. This is such a cute name it's hard to > imagine that it's not a local binding in numerous, invisible places. > > (Just last week I had to fix a package not on Hackage because it locally > defined (<>)...) > > On Fri, Sep 13, 2019, 7:54 AM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Tue, 10 Sep 2019, David Feuer wrote: >> >> > Every time I reach for Data.Function.on, I feel like a total dolt for >> having to import a module to get a function >> > whose implementation is barely longer than the import. And it's a >> really good function too! Can we please add it >> > to the Prelude? >> > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >> > (.*.) `on` f = \x y -> f x .*. f y >> >> Most of the time I would use this I can use the more specific 'equating' >> and 'comparing'. >> >> I remember there was a lengthy discussion about the right name of 'on' >> and >> adding it to Data.Function. I had no need for that function because at >> this point I already had: >> >> https://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Function-HT.html#v:compose2 >> >> If I am right the short name 'on' was only adopted because it was not >> (automatically) exported by >> Prelude._______________________________________________ >> 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 hesselink at gmail.com Sat Sep 14 18:51:18 2019 From: hesselink at gmail.com (Erik Hesselink) Date: Sat, 14 Sep 2019 20:51:18 +0200 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Fri, 13 Sep 2019 at 13:54, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Tue, 10 Sep 2019, David Feuer wrote: > > > Every time I reach for Data.Function.on, I feel like a total dolt for > having to import a module to get a function > > whose implementation is barely longer than the import. And it's a really > good function too! Can we please add it > > to the Prelude? > > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c > > (.*.) `on` f = \x y -> f x .*. f y > > Most of the time I would use this I can use the more specific 'equating' > and 'comparing'. > Does 'equating' exist in base now? I've always missed having that function in the past, and defined it myself many times. Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Sep 14 18:55:16 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 14 Sep 2019 20:55:16 +0200 (CEST) Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: On Sat, 14 Sep 2019, Erik Hesselink wrote: > Does 'equating' exist in base now? I've always missed having that > function in the past, and defined it myself many times. I import it from my utility-ht:Data.Eq.HT and thus stay independent from newer base versions. From godzbanebane at gmail.com Sat Sep 14 19:17:26 2019 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Sat, 14 Sep 2019 22:17:26 +0300 Subject: About WrappedMonoids deprecation Message-ID: Hello! Sorry if this is not the right place to ask! As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated . I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread . Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? Cheers, Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From j0villarreal at yahoo.com Sat Sep 14 20:36:26 2019 From: j0villarreal at yahoo.com (John Villarreal) Date: Sat, 14 Sep 2019 20:36:26 +0000 (UTC) Subject: About WrappedMonoids deprecation In-Reply-To: References: Message-ID: <1353397.9851064.1568493386159@mail.yahoo.com> Hello Georgi, I'm confused about WrappedMonoid. How can something have a Monoid instance already without having a Semigroup instance in the first place? But also what is the benefit of WrappedMonoid over the standard way of defining Semigroups and Monoids for your example data List a = Nil | Cons a (List a) instance Semigroup (List a) where  Nil       <> ys = ys  Cons x xs <> ys = Cons x (xs <> ys) instance Monoid (List a) where mempty = Nil ? Cheers,John On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov wrote: Hello! Sorry if this is not the right place to ask! As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated. I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread. Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? Cheers, Georgi_______________________________________________ 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 Sat Sep 14 20:47:03 2019 From: zemyla at gmail.com (Zemyla) Date: Sat, 14 Sep 2019 15:47:03 -0500 Subject: About WrappedMonoids deprecation In-Reply-To: <1353397.9851064.1568493386159@mail.yahoo.com> References: <1353397.9851064.1568493386159@mail.yahoo.com> Message-ID: The point is that someone can write instance Monoid Thingy where mempty = mappend a b = mconcat ls = deriving instance Semigroup Thingy via (WrappedMonoid Thingy) Most of the benefit is not having to look up "stimesMonoid" over and over again. On Sat, Sep 14, 2019 at 3:36 PM John Villarreal via Libraries wrote: > > Hello Georgi, > > > I'm confused about WrappedMonoid. How can something have a Monoid instance already without having a Semigroup instance in the first place? > > But also what is the benefit of WrappedMonoid over the standard way of defining Semigroups and Monoids for your example > > data List a = Nil | Cons a (List a) > > instance Semigroup (List a) where > Nil <> ys = ys > Cons x xs <> ys = Cons x (xs <> ys) > > instance Monoid (List a) where mempty = Nil > > ? > > Cheers, > John > > > On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov wrote: > > > Hello! > > Sorry if this is not the right place to ask! > > As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated. > > I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread. > > Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? > > Cheers, > Georgi > _______________________________________________ > 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 j0villarreal at yahoo.com Sat Sep 14 21:12:43 2019 From: j0villarreal at yahoo.com (John Villarreal) Date: Sat, 14 Sep 2019 21:12:43 +0000 (UTC) Subject: About WrappedMonoids deprecation In-Reply-To: References: <1353397.9851064.1568493386159@mail.yahoo.com> Message-ID: <711839447.9857099.1568495563856@mail.yahoo.com> Hi, I wasn't aware of that. I don't understand your a) and b) points though. Semigroup is a superclass of Monoid, so doesn't that already express the necessity that everyting which is a Monoid is also a Semigroup? And there's also no boilerplate manual aliasing in my version of your example, or is it? On Saturday, 14 September 2019, 20:52:56 UTC, Georgi Lyubenov wrote: Haskell allows you to "recursively" define instances of superclasses with functions defined in subclass instances. This is fine: ``` data List a ... instance Monoid (List a) ... -- give a definition for mappend here instance Semigroup (List a) where   (<>) = mappend ``` You can do a similar thing by first defining Monad for a type and then giving implementations for Functor and Applicative by using Control.Monad.liftM and Control.Monad.ap The benefit is that you can a) directly express the necessity that everything which is a Monoid is also a Semigroup already b) not write the boilerplate of manually aliasing (<>) to mappend (and in general for bigger chains of typeclasses/more typeclass functions this becomes more convenient) On Sat, Sep 14, 2019 at 11:36 PM John Villarreal wrote: Hello Georgi, I'm confused about WrappedMonoid. How can something have a Monoid instance already without having a Semigroup instance in the first place? But also what is the benefit of WrappedMonoid over the standard way of defining Semigroups and Monoids for your example data List a = Nil | Cons a (List a) instance Semigroup (List a) where  Nil       <> ys = ys  Cons x xs <> ys = Cons x (xs <> ys) instance Monoid (List a) where mempty = Nil ? Cheers,John On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov wrote: Hello! Sorry if this is not the right place to ask! As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated. I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread. Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? Cheers, Georgi_______________________________________________ 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 Sun Sep 15 02:17:57 2019 From: david.feuer at gmail.com (David Feuer) Date: Sat, 14 Sep 2019 22:17:57 -0400 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: I consider equating (and comparing) a bit of an anti-pattern. They're extra names to express what `on` does more generally, and barely save any characters over it On Sat, Sep 14, 2019, 2:51 PM Erik Hesselink wrote: > On Fri, 13 Sep 2019 at 13:54, Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Tue, 10 Sep 2019, David Feuer wrote: >> >> > Every time I reach for Data.Function.on, I feel like a total dolt for >> having to import a module to get a function >> > whose implementation is barely longer than the import. And it's a >> really good function too! Can we please add it >> > to the Prelude? >> > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >> > (.*.) `on` f = \x y -> f x .*. f y >> >> Most of the time I would use this I can use the more specific 'equating' >> and 'comparing'. >> > > Does 'equating' exist in base now? I've always missed having that function > in the past, and defined it myself many times. > > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Sun Sep 15 14:35:53 2019 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Sun, 15 Sep 2019 10:35:53 -0400 Subject: About WrappedMonoids deprecation In-Reply-To: References: <1353397.9851064.1568493386159@mail.yahoo.com> Message-ID: Although the example you give works today, it would stop working if mappend ever stopped being a typeclass method of Monoid. I cannot remember if this is on the roadmap. It's certainly not happening any time soon, but it may happen eventually. (It's similar in spirit to removing return from Monad) On Sat, Sep 14, 2019 at 4:48 PM Zemyla wrote: > The point is that someone can write > > instance Monoid Thingy where > mempty = > mappend a b = > mconcat ls = > > deriving instance Semigroup Thingy via (WrappedMonoid Thingy) > > Most of the benefit is not having to look up "stimesMonoid" over and over > again. > > On Sat, Sep 14, 2019 at 3:36 PM John Villarreal via Libraries > wrote: > > > > Hello Georgi, > > > > > > I'm confused about WrappedMonoid. How can something have a Monoid > instance already without having a Semigroup instance in the first place? > > > > But also what is the benefit of WrappedMonoid over the standard way of > defining Semigroups and Monoids for your example > > > > data List a = Nil | Cons a (List a) > > > > instance Semigroup (List a) where > > Nil <> ys = ys > > Cons x xs <> ys = Cons x (xs <> ys) > > > > instance Monoid (List a) where mempty = Nil > > > > ? > > > > Cheers, > > John > > > > > > On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov < > godzbanebane at gmail.com> wrote: > > > > > > Hello! > > > > Sorry if this is not the right place to ask! > > > > As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to > be deprecated. > > > > I believe that this newtype is actually useful in tandem with > DerivingVia, as it allows you to derive the Semigroup instance for > something that has a Monoid instance already, as discussed in this twitter > thread. > > > > Would it be possible to *not* deprecate it in the future, and instead > keep it around for exactly this purpose? > > > > Cheers, > > Georgi > > _______________________________________________ > > 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 > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Sun Sep 15 20:53:26 2019 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 16 Sep 2019 06:53:26 +1000 Subject: Proposal: Add cons function to Data.List module In-Reply-To: References: Message-ID: <5b4f8717-3ec6-3405-eabe-227a6eded02c@gmail.com> If we're looking at things like this, have you seen the At, Cons and Empty type-classes in lens? On 13/9/19 1:13 am, David Feuer wrote: > I think Michael Snoyman did a good job of starting that conversation > with his IsSequence class in mono-traversable. I don't agree with a > lot of the specific design decisions he's made, but I think we should > definitely think about previous experience in that space. > > Personally, I prefer an MPTC-based interface for the monomorphic > stuff. This is mostly a matter of taste, of course. One important > idea, of course, is that of a free monoid: > > type family Elem xs > > class e ~ Elem c => MonoFoldable e c where >   mfoldMap :: Monoid m => (e -> m) -> c -> m > > class (MonoFoldable e c, Monoid c) => MonoSequence e c where >   mSingleton :: e -> c >   -- All other methods can be optional > > class (forall e. Monoid (t e)) => Monoid1 t > instance (forall e. Monoid (t e)) => Monoid1 t > > class (Traversable t, Monoid1 t) => Sequence t where >   singleton :: e -> t e >   -- All other methods can be optional > > On Thu, Sep 12, 2019, 10:42 AM Andreas Abel > wrote: > > I think this proposal was be stronger if it would lay out the bigger > picture, i.e., directions towards a unified interface to > sequence-like > collections. > > -1 in its current form. > > On 2019-09-11 16:32, Helmut Schmidt wrote: > > Taylor, > > > > Is it really necessary for you to be so rude? I can assure you > that my > > proposal has been made in the same good faith as your proposal > which > > inspired mine. > > > > Besides that unnecessary snark you do make an excellent point > regarding > > the poor discoverability of the list constructor which I imagine > must > > cause a lot of confusion among newcomers.Thank you for keeping > an open mind! > > > > > > > > Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak > > > >>: > > > >     I suspect this proposal was not made in good faith. I feel > like it > >     was meant to make fun of my list singleton proposal. > > > >     In spite of that, I am in favor of this proposal. One of the > (very > >     minor!) problems with lists in Haskell is that they can’t be > >     documented with Haddock because they’re part of the syntax. For > >     example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you > >     won’t find the venerable list constructor. You will find > `cons` from > >     the `extra` package, which I think suggests that this > proposal is a > >     good idea. > > > >     +1 > > > >      > On Sep 11, 2019, at 4:13 AM, Oliver Charles > >      > >> wrote: > >      > > >      > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > >      > > >      >> wrote: > >      > > >      >> I can't be the only that wants this function, right? > >      > > >      > You're not the only one! I would also like this function. > In fact, > >      > only yesterday I found myself writing > >      > > >      >  ( x : ) <$> recurse xs > >      > > >      > I would have preferred > >      > > >      >  cons x <$> recurse xs > >      > > >      > +1 to adding  cons :: x -> [x] -> [x]  to  Data.List. > >      > > >      > Ollie > >      > _______________________________________________ > >      > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From george at wils.online Sun Sep 15 22:27:40 2019 From: george at wils.online (George Wilson) Date: Mon, 16 Sep 2019 08:27:40 +1000 Subject: Proposal: add `on` to the Prelude In-Reply-To: References: Message-ID: -1 I find `on` rather handy, but I would prefer that Prelude not claim so many identifiers, especially short ones like this. On Sun, 15 Sep 2019 at 12:18, David Feuer wrote: > > I consider equating (and comparing) a bit of an anti-pattern. They're extra names to express what `on` does more generally, and barely save any characters over it > > On Sat, Sep 14, 2019, 2:51 PM Erik Hesselink wrote: >> >> On Fri, 13 Sep 2019 at 13:54, Henning Thielemann wrote: >>> >>> >>> On Tue, 10 Sep 2019, David Feuer wrote: >>> >>> > Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function >>> > whose implementation is barely longer than the import. And it's a really good function too! Can we please add it >>> > to the Prelude? >>> > on :: (b -> b -> c) -> (a -> b) -> a -> a -> c >>> > (.*.) `on` f = \x y -> f x .*. f y >>> >>> Most of the time I would use this I can use the more specific 'equating' >>> and 'comparing'. >> >> >> Does 'equating' exist in base now? I've always missed having that function in the past, and defined it myself many times. >> >> Erik > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From zemyla at gmail.com Tue Sep 17 14:53:44 2019 From: zemyla at gmail.com (Zemyla) Date: Tue, 17 Sep 2019 09:53:44 -0500 Subject: Publicly exported pattern synonym for Ratios? Message-ID: Using the numerator and denominator functions in Data.Ratio adds an extra layer of laziness to functions that have to work with Ratios (especially Rationals). I think it'd be convenient if there were a pattern synonym exported from the safe Data.Ratio: pattern n :% d <- (n GHC.Ratio.:% d) where n :% d = n % d This way, destructuring is as fast as if you were to import GHC.Ratio directly, but it can't be used to create invalid Ratios. The only disadvantage is that using the :% to destructure it requires an Integral constraint on the value, but 99% of the time, the value will be Integer anyway, and even in the remaining 1% you still can't construct a Ratio a without an Integral a constraint in safe code anyway, so it shouldn't matter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From V.Liepelt at kent.ac.uk Wed Sep 18 10:48:44 2019 From: V.Liepelt at kent.ac.uk (V.Liepelt) Date: Wed, 18 Sep 2019 10:48:44 +0000 Subject: Add NonEmptyMap and NonEmptySet to containers Message-ID: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> Hi John, I saw your thread about non-empty containers today. Why not call them `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? I think most agree that `NonEmpty` is not a great name—I couldn’t summarise it better than Andreas: "NonEmpty what?”. Hence I always do the following: ``` import Data.List.NonEmpty (NonEmpty) import qualified Data.List.NonEmpty as List1 type List1 = NonEmpty ``` In fact I just hoogled for this and noticed that the rebase package seems to do this too. More anecdotal precedent: recently a colleague wrote a datatype isomorphic to `(a, a, [a])` and called it something not quite as ridiculous as `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody involved was happy with that. Vilem From alexandre.fmp.esteves at gmail.com Fri Sep 20 01:17:16 2019 From: alexandre.fmp.esteves at gmail.com (Alexandre Esteves) Date: Fri, 20 Sep 2019 02:17:16 +0100 Subject: Add NonEmptyMap and NonEmptySet to containers In-Reply-To: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> References: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> Message-ID: Yet more precedent: https://hackage.haskell.org/package/semigroupoids-5.3.3/docs/Data-Semigroup-Foldable.html#t:Foldable1 I do like the sound of `instance Foldable1 Set1` more than I do `instance NonEmptyFoldable NonEmptySet` On Wed, Sep 18, 2019 at 11:49 AM V.Liepelt wrote: > Hi John, > > I saw your thread about non-empty containers today. Why not call them > `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? > > I think most agree that `NonEmpty` is not a great name—I couldn’t > summarise it better than Andreas: "NonEmpty what?”. Hence I always do the > following: > > ``` > import Data.List.NonEmpty (NonEmpty) > import qualified Data.List.NonEmpty as List1 > > type List1 = NonEmpty > ``` > > In fact I just hoogled for this and noticed that the rebase package seems > to do this too. > > More anecdotal precedent: recently a colleague wrote a datatype isomorphic > to `(a, a, [a])` and called it something not quite as ridiculous as > `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody involved > was happy with that. > > Vilem > _______________________________________________ > 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 Fri Sep 20 01:49:47 2019 From: zemyla at gmail.com (Zemyla) Date: Thu, 19 Sep 2019 20:49:47 -0500 Subject: Add NonEmptyMap and NonEmptySet to containers In-Reply-To: References: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> Message-ID: Counterpoint: Generic1 refers to a higher kinded Generic, not a nonempty one. On Thu, Sep 19, 2019, 20:17 Alexandre Esteves < alexandre.fmp.esteves at gmail.com> wrote: > Yet more precedent: > https://hackage.haskell.org/package/semigroupoids-5.3.3/docs/Data-Semigroup-Foldable.html#t:Foldable1 > I do like the sound of `instance Foldable1 Set1` more than I do `instance > NonEmptyFoldable NonEmptySet` > > > > On Wed, Sep 18, 2019 at 11:49 AM V.Liepelt wrote: > >> Hi John, >> >> I saw your thread about non-empty containers today. Why not call them >> `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? >> >> I think most agree that `NonEmpty` is not a great name—I couldn’t >> summarise it better than Andreas: "NonEmpty what?”. Hence I always do the >> following: >> >> ``` >> import Data.List.NonEmpty (NonEmpty) >> import qualified Data.List.NonEmpty as List1 >> >> type List1 = NonEmpty >> ``` >> >> In fact I just hoogled for this and noticed that the rebase package seems >> to do this too. >> >> More anecdotal precedent: recently a colleague wrote a datatype >> isomorphic to `(a, a, [a])` and called it something not quite as ridiculous >> as `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody >> involved was happy with that. >> >> Vilem >> _______________________________________________ >> 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 ruben.astud at gmail.com Fri Sep 20 01:56:26 2019 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 19 Sep 2019 22:56:26 -0300 Subject: Add NonEmptyMap and NonEmptySet to containers In-Reply-To: References: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> Message-ID: On 19-09-19 22:17, Alexandre Esteves wrote: > I do like the sound of `instance Foldable1 Set1` more than I do > `instance NonEmptyFoldable NonEmptySet` > I prefer it too, I just wish (future) documentation included a little explanation on why the suffix 1 was put. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD From abela at chalmers.se Fri Sep 20 05:13:43 2019 From: abela at chalmers.se (Andreas Abel) Date: Fri, 20 Sep 2019 07:13:43 +0200 Subject: Add NonEmptyMap and NonEmptySet to containers In-Reply-To: References: <505415F3-D529-4A16-AB78-B514DF6316EA@kent.ac.uk> Message-ID: I think the origin of the suffix 1 is e.g. the function foldr1 :: (a -> a -> a) -> [a] -> a which is a fold for non-empty lists only. That use of "1" might be older than the use of "1" for order-1 type constructors. On 2019-09-20 03:56, Ruben Astudillo wrote: > On 19-09-19 22:17, Alexandre Esteves wrote: >> I do like the sound of `instance Foldable1 Set1` more than I do >> `instance NonEmptyFoldable NonEmptySet` >> > > I prefer it too, I just wish (future) documentation included a little > explanation on why the suffix 1 was put. > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From omeragacan at gmail.com Tue Sep 24 10:44:17 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 24 Sep 2019 13:44:17 +0300 Subject: Package take over: regex-{base,compat,pcre,posix} In-Reply-To: References: Message-ID: +1 This package is currently causing so much trouble when testing GHC HEAD because it's used by some of the widely used packages and GHC testing/benchmark infra (e.g. nofib-analyse). Ömer Andres Sicard Ramirez , 9 Eyl 2019 Pzt, 18:49 tarihinde şunu yazdı: > > +1. In Agda we are waiting that regex-base supports GHC 8.8.1 (see https://github.com/ChrisKuklewicz/regex-tdfa/issues/23). > > On Sat, 7 Sep 2019 at 06:29, Herbert Valerio Riedel wrote: >> >> Hello everyone, >> >> I tried to contact Christopher Kuklewicz on May 10, 2019 via the two email addresses associated with his packages (also CC'ed in this email) but got no response. >> >> I hereby invoke the protocol as per https://wiki.haskell.org/Taking_over_a_package to take over the packages mentioned in the subject line which haven't seen any release to Hackage since May 2012 as the most recent upload events for these packages show: >> >> 2012-05-30T21:44:34Z ChrisKuklewicz regex-pcre-0.94.4-r0 >> 2012-05-20T16:46:16Z ChrisKuklewicz regex-pcre-0.94.3-r0 >> 2012-05-20T16:35:59Z ChrisKuklewicz regex-posix-0.95.2-r0 >> 2011-05-09T18:01:58Z ChrisKuklewicz regex-compat-0.95.1-r0 >> 2011-05-09T15:55:55Z ChrisKuklewicz regex-posix-0.95.1-r0 >> 2011-05-09T15:29:42Z ChrisKuklewicz regex-posix-0.95.0-r0 >> 2010-07-20T10:58:10Z ChrisKuklewicz regex-posix-0.94.4-r0 >> 2010-06-11T23:01:36Z ChrisKuklewicz regex-posix-0.94.2-r0 >> 2010-06-11T23:00:42Z ChrisKuklewicz regex-pcre-0.94.2-r0 >> 2010-06-11T22:59:26Z ChrisKuklewicz regex-compat-0.93.1-r0 >> 2010-06-11T22:58:19Z ChrisKuklewicz regex-base-0.93.2-r0 >> >> This package take-over is also tracked at https://github.com/haskell-infra/hackage-trustees/issues/238 >> La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > Andrés > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From athas at sigkill.dk Tue Sep 24 11:21:04 2019 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 24 Sep 2019 13:21:04 +0200 Subject: Package take over: regex-{base,compat,pcre,posix} In-Reply-To: (=?utf-8?Q?=22=C3=96mer?= Sinan =?utf-8?Q?A=C4=9Facan=22's?= message of "Tue, 24 Sep 2019 13:44:17 +0300") References: Message-ID: Ömer Sinan Ağacan writes: > +1 This package is currently causing so much trouble when testing GHC HEAD > because it's used by some of the widely used packages and GHC testing/benchmark > infra (e.g. nofib-analyse). hvr took it over: https://github.com/haskell-hvr/regex-base He told me on IRC he wants to make some fixes to the related regex-posix before putting them Hackage. -- \ Troels /\ Henriksen