From kindaro at gmail.com Thu Jul 1 06:58:24 2021 From: kindaro at gmail.com (Ignat Insarov) Date: Thu, 1 Jul 2021 11:58:24 +0500 Subject: New Libraries Proposal process In-Reply-To: References: Message-ID: > Pull request on ghc gitlab and then link to it here for folks to review it. > > Grounded patches solve all sorts of ambiguity. Having another proposal process doesn’t solve that. :) Carter, I completely fail to understand any of your three sentences. 1. What does GHC have to do with any of this? I am talking about proposals to core libraries, not GHC. 2. What is a grounded patch? What is the ambiguity you are talking about? From kindaro at gmail.com Thu Jul 1 06:59:53 2021 From: kindaro at gmail.com (Ignat Insarov) Date: Thu, 1 Jul 2021 11:59:53 +0500 Subject: Strict folds without base case to `Data.Foldable`. In-Reply-To: References: <87sg0zk00b.fsf@gmail.com> <81905f1f-20f2-3acb-7ee1-caae68f69eaf@henning-thielemann.de> Message-ID: > Since there is no `foldl1'` class method to override, no structures > have a specialised definition. Therefore, a "default" definition > can be written outside the class … I know, Viktor. I have already written a definition very similar to yours. I even said in my first message that the implementation is trivial. The question is whether I should accept that patching over deficiencies of `base` is normal. > P.S. FWIW, apologies if I am misreading the tone of your message, but > it does sound "demanding" to me. GHC is a free community project … This is exactly why I am still here. Even though I have seen good and worthy proposals drowned in endless pondering over minutiae. Do I want to help improve the common goods? Yes. Am I happy with how it has been going so far? No. > … with > no large corporation invested in its development, all the contributors > want to help users, but this is easier to help users who are considerate > of those to would volunteer their time to help. This is not about _«help»_. I am not asking for help. I have technical requirements from a certain library, here `base`. I made the maintainers aware of these requirements. I cannot force the maintainers to improve the library, the maintainers cannot cancel my requirement. From hasufell at posteo.de Thu Jul 1 08:12:56 2021 From: hasufell at posteo.de (Julian Ospald) Date: Thu, 01 Jul 2021 08:12:56 +0000 Subject: New Libraries Proposal process In-Reply-To: References: Message-ID: You want to change base. base release schedule is tied to GHC and is in fact part of its git tree: https://gitlab.haskell.org/ghc/ghc/-/tree/master/libraries/base By providing a clear patch with reasoning and motivation, you're reducing the possibility of bikeshedding. ML is for bikeshedding and getting a picture of community opinion. I believe your patch doesn't require any of that. If the GHC team/CLC thinks so, they'll let you know on your PR. My experience even with patches to core libraries is also mixed. Last time I tried to provide something as simple as forM to Data.Set. It took 1 year to even get to an actual review. Then the patch was 90% done, but failed because of the remaining 10% that the maintainers weren't able to make clear to me. IMO, these days it's hard to get contributors anyway. I personally merge PRs even if they're just 80% done and fix the rest myself. I don't expect there to be issues with base though. GHC developers are responsive. On July 1, 2021 6:58:24 AM UTC, Ignat Insarov wrote: >> Pull request on ghc gitlab and then link to it here for folks to >review it. >> >> Grounded patches solve all sorts of ambiguity. Having another >proposal process doesn’t solve that. :) > >Carter, I completely fail to understand any of your three sentences. > >1. What does GHC have to do with any of this? I am talking about >proposals to core libraries, not GHC. >2. What is a grounded patch? What is the ambiguity you are talking >about? >_______________________________________________ >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 kindaro at gmail.com Thu Jul 1 08:54:15 2021 From: kindaro at gmail.com (Ignat Insarov) Date: Thu, 1 Jul 2021 13:54:15 +0500 Subject: New Libraries Proposal process In-Reply-To: References: Message-ID: Thanks Julian. Last time I opened an issue to `containers` they sent me straight to this mailing list. So I assumed the same would happen if I make a pull request to add something to `base`. But maybe you are right and it is going to go differently. I am going to try it and report back. From ietf-dane at dukhovni.org Thu Jul 1 12:01:18 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Jul 2021 08:01:18 -0400 Subject: New Libraries Proposal process In-Reply-To: References: Message-ID: On Thu, Jul 01, 2021 at 01:54:15PM +0500, Ignat Insarov wrote: > Last time I opened an issue to `containers` they sent me straight to > this mailing list. So I assumed the same would happen if I make a pull > request to add something to `base`. But maybe you are right and it is > going to go differently. I am going to try it and report back. What might help in this case is some motivating context that would help to overcome the objection that you're suggesting yet more partial functions for Data.Foldable, which perhaps belong in a new Foldable1 class, of which 'NonEmpty' can be the poster-child instance. Would 'Foldable1' work for you? Do you need it to be derivable? ... -- Viktor. From ben at smart-cactus.org Thu Jul 1 13:58:35 2021 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 01 Jul 2021 09:58:35 -0400 Subject: Regarding dupe Re: New Libraries Proposal process In-Reply-To: References: <20200912134410.GA3794@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <20200912232552.GB20551@painter.painter> Message-ID: <87y2aqxhjb.fsf@smart-cactus.org> Carter Schonwald writes: > I think wrt to the dup/dupe proposal the answer at the time was nope. > 1) there wasn’t a clear name that wouldn’t collide with user code > > 2) it wasn’t clear that it provided new expressive power / reduced > complexity. > > To be clear, there’s a higher bar for adding / changing exports of > preexisting modules, and preexisting wide spread conventions in programming > practice is often a good way to motivate including such operations. Or that > it adds a meaningful abstraction that helps all users. > > Also there didn’t seem to be much wide spread support in the discussion > that followed. > > @simon : that process doesn’t have clear buy in by those who participate > actively in the libraries ecosystem. And raises questions around > For what it's worth, I agree that it would be beneficial to have a more formal libraries proposal process. The current process has a number of shortcomings: * it has shown itself to be lossy; that is, proposals are sometimes lost * intransparent: I have found it difficult to locate clear conclusions on mailing lists threads when evaluating ghc core libraries MRs. * difficult to audit: when one does find a message that looks authoritative are carries a clear conclusion, it often isn't clear whether this is the opinion of the body as a whole, or simply one member. * may be poorly representative: recently most of my interactions with the CLC have been by pinging @core-libraries on GHC MRs, where I get at most one or two replies. My fear is that while the nominal size of the body is ~9 members, only a few members are actively engaged, suggesting that there may be a deeper problem with the structure of the body In my opinion the opening of Carter's message ("I think ...") captures the problem here rather well: there is no single place where conclusions are clearly articulated and flagged as such. All we can do is trawl through mailing list threads of yore and attempt to reconstruct the collective state-of-mind of the committee. This is what Chessai's proposal seeks to fix. > 1) I don’t think we have enough volunteer effort to actually manage / > support Such a process (it’s tantamount to expecting full time > professionalization expectations for libraries core contrib... which I > think our community and industrial sponsorship isn’t large enough to > facilitate. ). Plus that dramatically increases the participation > expectations / requirements from clc members. > I don't believe anyone is suggesting that the process should require a full-time employee to manage. Rather, I would point to the GHC Proposals process as a process that is reasonably formal, effective, and yet operates on relatively little time investment by its steering committee. Given that the CLC's responsibilities are at least as important as those of the GHC Steering committee, I see little reason why this couldn't, or shouldn't, be replicated. Of course, any more formal process will likely require time investment than the status quo. To this end, I think it would be beneficial for the CLC to discusss the expected time commitment required by the body and what time individual members are able to provide. If the time investment necessary for an improved process is greater than the volunteer effort available then there are three options: (a) scale down the process, (b) increase the size of the committee, or (c) kindly thank existing members who aren't able to put effort into the body for their service and ask that they step down. > 2) it creates authority that frankly clc did not have before. (Ed and > others who have been part of clc historically please correct me if I’m > wrong). Clc is supposed to be a facilitator and tie breaker and guider of > evolution of base and a mechanisms for engaging in community consensus of > how to improve important libraries. > I completely agree with your last sentence. However, in light of this I'm not sure I understand the point made in your first sentence: What new authority are you seeing in Chessai's proposal? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri Jul 2 15:26:30 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 2 Jul 2021 11:26:30 -0400 Subject: Export Natural type from prelude Message-ID: This seems long overdue and aside from some redundant import warnings likely low breakage risk Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Fri Jul 2 15:42:42 2021 From: chessai1996 at gmail.com (chessai) Date: Fri, 2 Jul 2021 10:42:42 -0500 Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: +1, along with Int{8,16,32,64} & Word{8,16,32,64} On Fri, Jul 2, 2021, 10:27 Carter Schonwald wrote: > This seems long overdue and aside from some redundant import warnings > likely low breakage risk > > > Thoughts? > _______________________________________________ > 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 sandy at sandymaguire.me Fri Jul 2 15:44:36 2021 From: sandy at sandymaguire.me (Sandy Maguire) Date: Fri, 2 Jul 2021 08:44:36 -0700 Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: Yes please. On Fri, Jul 2, 2021 at 8:43 AM chessai wrote: > +1, along with Int{8,16,32,64} & Word{8,16,32,64} > > On Fri, Jul 2, 2021, 10:27 Carter Schonwald > wrote: > >> This seems long overdue and aside from some redundant import warnings >> likely low breakage risk >> >> >> Thoughts? >> _______________________________________________ >> 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 lemming at henning-thielemann.de Fri Jul 2 15:48:18 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 2 Jul 2021 17:48:18 +0200 (CEST) Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021, chessai wrote: > +1, along with Int{8,16,32,64} & Word{8,16,32,64} IntN and WordN are quite a different topic. They belong to low-level programming. From ollie at ocharles.org.uk Fri Jul 2 15:50:50 2021 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 02 Jul 2021 16:50:50 +0100 Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: <3893a5e5-41e4-4df2-a096-976011172c3b@www.fastmail.com> Not to derail, but I am +1 on the original suggestion, but +10 on Int* and Word* On Fri, 2 Jul 2021, at 4:42 PM, chessai wrote: > +1, along with Int{8,16,32,64} & Word{8,16,32,64} > > On Fri, Jul 2, 2021, 10:27 Carter Schonwald wrote: >> This seems long overdue and aside from some redundant import warnings likely low breakage risk >> >> >> Thoughts? >> _______________________________________________ >> 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 lemming at henning-thielemann.de Fri Jul 2 15:56:19 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 2 Jul 2021 17:56:19 +0200 (CEST) Subject: Export Natural type from prelude In-Reply-To: <3893a5e5-41e4-4df2-a096-976011172c3b@www.fastmail.com> References: <3893a5e5-41e4-4df2-a096-976011172c3b@www.fastmail.com> Message-ID: <3284472c-45f8-c51e-9bf1-d512d020cc9a@henning-thielemann.de> On Fri, 2 Jul 2021, Oliver Charles wrote: > Not to derail, but I am +1 on the original suggestion, but +10 on Int* and Word* Can people please not only say +1, but also tell some reasons? From ollie at ocharles.org.uk Fri Jul 2 16:43:00 2021 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 02 Jul 2021 17:43:00 +0100 Subject: Export Natural type from prelude In-Reply-To: <3284472c-45f8-c51e-9bf1-d512d020cc9a@henning-thielemann.de> References: <3893a5e5-41e4-4df2-a096-976011172c3b@www.fastmail.com> <3284472c-45f8-c51e-9bf1-d512d020cc9a@henning-thielemann.de> Message-ID: <4bcb0769-92c2-4f56-a60d-ab8d7803df0c@www.fastmail.com> On Fri, 2 Jul 2021, at 4:56 PM, Henning Thielemann wrote: > > On Fri, 2 Jul 2021, Oliver Charles wrote: > > > Not to derail, but I am +1 on the original suggestion, but +10 on Int* and Word* > > Can people please not only say +1, but also tell some reasons? Natural is frequently a much more correct type than Int or Integer, as it naturally (ha) rules out needing to think about negative cases. Int* and Word* are frequently what I need to ultimately consume or produce. I don't agree they are "low-level", unless we consider any boundary to be low-level. But even then, if I ultimately have to produce Int64, I don't want to overflow a million miles away and then suddenly fail at the boundary. Int64 _is_ the correct type throughout the whole system I'm building. Unless my whole system is low-level, but that's a subjective judgement. I also don't think we can consider Int any less low-level - it's still bounded, but in a sense even less predictably due to varying depending on the underlying architecture. Due to needing them frequently, I just find it tedious to have to import them every time when they are perfectly uncontroversial (well, to me, anyway). Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Jul 2 16:54:03 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Jul 2021 12:54:03 -0400 Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: I'm going to play devil's advocate and say no. I believe Num instances should be rings under + and *. Natural is an instance of Num but is not a ring. On Fri, Jul 2, 2021, 11:26 AM Carter Schonwald wrote: > This seems long overdue and aside from some redundant import warnings > likely low breakage risk > > > Thoughts? > _______________________________________________ > 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 Fri Jul 2 19:16:32 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 2 Jul 2021 15:16:32 -0400 Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: This is a good point were we adding it to base. It’s already in base and widely useful! That’s a good motivation to add for fixing num and friends. But that’s not even a new problem for num instances in base. Reexport it from prelude doesn’t change that. Just improves the ergonomics for using a really nice type for both pedagogy and prototyping! I also like how natural throws an error on underflow. On Fri, Jul 2, 2021 at 12:54 PM David Feuer wrote: > I'm going to play devil's advocate and say no. I believe Num instances > should be rings under + and *. Natural is an instance of Num but is not a > ring. > > On Fri, Jul 2, 2021, 11:26 AM Carter Schonwald > wrote: > >> This seems long overdue and aside from some redundant import warnings >> likely low breakage risk >> >> >> Thoughts? >> _______________________________________________ >> 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 R.Paterson at city.ac.uk Sat Jul 3 19:56:19 2021 From: R.Paterson at city.ac.uk (Paterson, Ross) Date: Sat, 3 Jul 2021 19:56:19 +0000 Subject: Export Natural type from prelude In-Reply-To: References: , Message-ID: Carter Schonwald wrote: > This is a good point were we adding it to base. It’s already in base and widely useful! > > That’s a good motivation to add for fixing num and friends. But that’s not even a new problem for num instances in base. Reexport it from prelude doesn’t change that. Just improves the ergonomics for using a really nice type for both pedagogy and prototyping! > > I also like how natural throws an error on underflow. That seems the wrong way round. There's lots of stuff in base, but the Prelude is part of the language definition. A higher standard should apply. The numeric classes do indeed need fixing. When that is done, it will be necessary to preserve backwards compatibility, which is difficult but mostly possible. But adding another bad instance to the language now, including (-) :: Natural -> Natural -> Natural will make that more difficult. Besides, the trend for some time has been to avoid partial functions. From oleg.grenrus at iki.fi Mon Jul 5 09:39:38 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 5 Jul 2021 12:39:38 +0300 Subject: RFC: Add HasCallStack constraint to partial Data.List functions. In-Reply-To: <748a86ea-6f01-0970-1fb5-002295f7ae82@iki.fi> References: <748a86ea-6f01-0970-1fb5-002295f7ae82@iki.fi> Message-ID: <3edcb1ed-0996-de7d-8624-04b5a6cb9f1d@iki.fi> The discussion period for this proposal have ended. The most meritorious counter-argument/proposal is using Partial constraint. [1] I don't have counterarguments which would allow me simply discard that. I encourage Richard and Henrik to pursue that plan. So I have decided to drop this, HasCallStack, proposal. - Oleg P.S. I'd like to have formal process (like in [2]), and make a body (CLC?) to decide whether the alterantives have merits, so the process would have chance to make progress. [1]: https://mail.haskell.org/pipermail/libraries/2021-June/031291.html [2]: https://mail.haskell.org/pipermail/libraries/2021-July/031339.html On 30.5.2021 16.52, Oleg Grenrus wrote: > I'm proposing to add HasCallStack constraint for partial functions > in base package for functions in Data.List and Data.List.NonEmpty: > > - head, tail, init, last, ... > - foldr1, foldl1, maximum, minimum, ... > - (!!) > > --- > > The previous discussions started by Luo Chen can be found at > https://gitlab.haskell.org/ghc/ghc/-/issues/17040 (from August 2019) > > and libraries list from June 2019 > https://mail.haskell.org/pipermail/libraries/2019-June/029652.html > > --- > > My motivation comes from seeing GHCJS failing with > "Prelude.!! negative index" exception and > cabal-install with head of empty list. > > --- > > In #17040 issue Ben Gamari comments [1] > >> In general, adding HasCallStack constraints on things like simple >> non-recursive functions like fromJust and head seems like a reasonable >> trade-off; these functions will essentially always inline and >> consequently the cost of the constraint will vanish. > Such patch is now available at > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833 > > After accepting few changed test outputs, no further changes were needed. > > --- > > Ben continues: > >> Adding HasCallStack constraints on typeclass-overloaded methods isn't >> as clear. After all, it's quite likely that these functions will be >> reached by dynamic dispatch which will become more expensive with the >> additional callstack argument. > I agree. Foldable.foldr1 may not be partial, e.g. it isn't for NonEmpty. > > More correct approach would be to add Foldable1 [2] class to base, and > in some distant future remove potentially partial members from Foldable. > > Therefore my patch _does not change_ Foldable. > >> nofib may not be a very good test for this patch as it doesn't contain >> many uses of the affected functions > Indeed. These functions are hardly ever in tight performance critical > code, thus I'm skeptical about they affecting a code written by > performance aware people. Re-implementing `head` in a loop where it > causes performance regression is trivial. > > I have run `nofib` anyway. Results are at the end. > >> I think it would be a good idea to start with a minimal patch adding >> constraints to the simple cases. We should then verify that the patch >> doesn't affect the Core produced by typical use-cases (perhaps even >> adding tests such that these don't regress). Once we know that the >> simple cases are safe we can move on to the harder cases. > Such patch is now available at > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833 > > --- > > Let me go through other comments in previous discussions, to have fuller > overview. > > --- > > Some people are in favour, e.g. > - Simon Jakobi, > https://mail.haskell.org/pipermail/libraries/2019-June/029655.html > - Hécate, https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_355561 > > --- > > Richard [3] thinks that e.g. a year prior addition of HasCallStack to > fromJust > [4] is not a right thing. > >> I don't have any particular insight to how to do call stacks better -- >> and I am swayed by the argument that we need call stacks even in >> production -- but I don't think HasCallStack is the way. That was >> always meant as just a small hack! > This patch is indeed more pragmatic than elegant, but takes us from > takes us from spending potentially many hours finding the source of a > crash to being pointed at the very line where it happens directly, which > is invaluable for production systems.  I.e. let not (unknown) perfect be > an enemy of good solution. > > --- > > In fromJust issue discussion [4] Ben comments > >> However, I should emphasize to that we don't want to simply scatter >> HasCallStacks on every partial function. We should be thoughtful and >> deliberate (and probably consult with the CLC) when making changes >> like this. > This email is indeed a request for CLC to comment. > > --- > > Edward Kmett comments was in favour [5] > >> I’m starting to warm to the idea of putting HasCallStack constraints >> on the obviously partial combinators in base if we can demonstrate >> that the performance impact isn't bad in practice, and even really, to >> some extent if there is a somewhat middling impact on the performance >> of code that leans on these hard to debug combinators, so long as the >> performance of their more total siblings remains unaffected. The >> impact on the perceived debuggability of Haskell seems _likely_ to >> significantly outweigh the performance concerns. > The results (to follow) shows that impact isn't bad. > >> Heck, off of the HEAD of cabal, which we’re encouraging folks to build >> to play with the ghc 8.8.1 alpha, just today we ran into an issue >> where the very build system we are using spat out an oh so informative >> “Prelude.foldr1: Empty list” when using a pkgconfig-depends stanza >> that didnt include any explicit bounds. > --- > > David Feuer is worried about performance of recursive functions [6] > >> As I recall, the main things to watch out for, performance-wise, are >> recursive definitions. When we throw an error from a library function, >> we *typically* mean that the caller made a mistake. We don't want to >> build up the call stacks we'd need to debug the library function >> itself, unless we're actually doing so (in which case we can edit it >> in, of course). > In current base implementation all recursive functions (like foldr1, or > !!) have internal workers, so the callstack is not building-up. > > Eric Seidel comments later [8] > >> What I remember finding back then was that there was a small overhead >> for non-recursive functions like `head` but a substantial overhead for >> recursive functions. >>   I'd suggest extra care around recursive functions ((!!) comes to >>   mind).  Perhaps rewrite them to use an inner recursive loop that does >>   not extend the CallStack (this might produce nicer stacktraces >>   anyway). > That is how (!!) is currently written in base. It has an inner worker. > (His benchmark link is not valid anymore, so I cannot tell what !! > variant he benchmarked). > > --- > > Matthew Pickering comments [7] about -xc RTS flag. > >> I find this thread a bit concerning. In my opinion the current best >> way to get call stacks on exceptions is with `-xc`. Adding runtime >> overhead to every user program is not acceptable. > -xc requires recompiling the program for profiling. > > He continues with > >> There is an argument that it would be good to disentangle `-xc` from >> `prof` but you would still have to compile `base` in this way which >> instruments these partial functions (as a user can not do it herself). >> I'm not too sure on the details but I don't think -xc uses any >> information from the profiling header so the fact it's connected with >> -prof seems more like convenience than necessity. > If that work is done, we can drop HasCallStack from partial functions, > until then again let not perfect be the enemy of good. > > For example, me seeing GHCJS throwing on !!, of Edward cabal-install on > foldr1 doesn't help. Rebuilding cabal-install with profiling is viable > (but not for an average person who downloads it with ghcup), > rebuilding GHCJS for profiling is a skill few people have. > > Already in his original proposal Luo Chen says: > >> When we run a long running program, such as a web service, it is not >> easy to reproduce the issue, most of the time, you have no chance to >> recompile or restart your program to debug, all you can rely on is the >> printed logs, this makes -xc not as useful as HasCallStack. > --- > > People are worried about performance. > GHC itself uses some of the a affected functions. > There are 30 foldr1, some head and tail calls, and also !! in `compiler/` > > The performance metrics in MR do not regress. > GHC is not slowed down. > > I also run `nofib` using `--cachegrind -s Norm -j 16`, geometric means: > > - allocations: -0.12% > - instructions: +0.05% > - LLC cache misses: +0.58% > - L1 cache misses: +0.03% > > And also using `--perf` (without `-j`): > > - perf instructions: +0.02% > - perf cycles: -0.80% > > I don't know if this in bounds of "small changes to GHC". > For me this looks acceptable. > > --- > > There is also off-thread blog post from 2018. > https://neilmitchell.blogspot.com/2018/03/safe-library-with-better-stack-traces.html > referencing e.g. > https://hackage.haskell.org/package/extra-1.7.9/docs/Data-List-Extra.html#v:maximumOn > and https://hackage.haskell.org/package/safe > > safe library has plenty of reverse dependencies: > https://packdeps.haskellers.com/reverse/safe, and extra is used by shake. > > --- > > In summary: > > - fromJust has HasCallStack, head doesn't. Let us fix this. > - Ben asked for patch so we can test performance, now such patch exists, >   and it passes GHC CI. > - GHC itself uses partial functions, its performance metrics don't >   regress > - -prof and +RTS -xc is an option, but it needs special build of an >   executable. > - This is ultimately for CLC to decide, so chessai, emilypi please tell >   your opinion. > > Discussion period one month, until 2021-06-30 (end of June this year). > > Oleg > > [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_231634 > [2]: https://mail.haskell.org/pipermail/libraries/2019-November/030059.html >      https://gitlab.haskell.org/ghc/ghc/-/issues/13573 > [3]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_218035 > [4]: https://gitlab.haskell.org/ghc/ghc/-/issues/15559 > [5]: https://mail.haskell.org/pipermail/libraries/2019-June/029665.html > [6]: https://mail.haskell.org/pipermail/libraries/2019-June/029666.html > [7]: https://mail.haskell.org/pipermail/libraries/2019-June/029672.html > [8]: https://mail.haskell.org/pipermail/libraries/2019-June/029667.html > > --- > > # bytes allocated > > +-------------------------------++--+-------------+------------------+ > |                               ||  |     master/ | callstack/ (rel) | > +===============================++==+=============+==================+ > |          imaginary/bernouilli ||  |     2.823e9 |            0.00% | > |        imaginary/digits-of-e1 ||  |     1.069e9 |            0.00% | > |        imaginary/digits-of-e2 ||  |     2.152e9 |            0.00% | > |              imaginary/exp3_8 ||  |     5.888e9 |            0.00% | > |         imaginary/gen_regexps ||  |     9.104e8 |            0.00% | > |           imaginary/integrate ||  |     3.768e9 |            0.00% | > |               imaginary/kahan ||  |   49088.000 |            0.00% | > |           imaginary/paraffins ||  |     3.829e9 |            0.00% | > |              imaginary/primes ||  |     2.928e9 |            0.00% | > |              imaginary/queens ||  |     6.709e8 |            0.00% | > |                imaginary/rfib ||  |  139952.000 |            0.00% | > |                 imaginary/tak ||  |   97344.000 |            0.00% | > |        imaginary/wheel-sieve1 ||  |     1.344e8 |            0.00% | > |        imaginary/wheel-sieve2 ||  |     2.430e9 |            0.00% | > |                imaginary/x2n1 ||  |     2.561e8 |            0.00% | > |         parallel/blackscholes ||  |     1.980e9 |            0.00% | > |                parallel/coins ||  |     5.252e9 |            0.00% | > |                 parallel/gray ||  |     2.010e9 |           +0.00% | > |               parallel/mandel ||  |     8.524e9 |            0.00% | > |              parallel/matmult ||  |     8.974e7 |            0.00% | > |              parallel/minimax ||  |    2.212e10 |            0.00% | > |                parallel/nbody ||  | 1498304.000 |            0.00% | > |               parallel/parfib ||  |     3.651e8 |            0.00% | > |              parallel/partree ||  |     3.290e9 |            0.00% | > |                 parallel/prsa ||  |     2.097e9 |            0.00% | > |               parallel/queens ||  |     6.846e8 |            0.00% | > |                  parallel/ray ||  |    1.357e10 |            0.00% | > |             parallel/sumeuler ||  | 1785016.000 |            0.00% | > |            parallel/transclos ||  |     8.976e9 |            0.00% | > |                     real/anna ||  |     2.022e9 |           +0.01% | > |             real/ben-raytrace ||  |    3.418e10 |            0.00% | > |                     real/bspt ||  |     3.747e9 |            0.00% | > |                real/cacheprof ||  |     2.689e9 |            0.00% | > |                 real/compress ||  |     2.807e9 |            0.00% | > |                real/compress2 ||  |     3.436e9 |            0.00% | > |                   real/eff/CS ||  |     1.601e8 |            0.00% | > |                  real/eff/CSD ||  |     1.600e9 |            0.00% | > |                   real/eff/FS ||  |     1.760e9 |            0.00% | > |                    real/eff/S ||  |     2.401e8 |            0.00% | > |                   real/eff/VS ||  |     4.831e8 |            0.00% | > |                  real/eff/VSD ||  |   50736.000 |            0.00% | > |                  real/eff/VSM ||  |     4.001e8 |            0.00% | > |                      real/fem ||  |     4.947e9 |           -2.81% | > |                    real/fluid ||  |     2.169e9 |           -0.00% | > |                   real/fulsom ||  |     1.961e9 |            0.00% | > |                   real/gamteb ||  |     4.447e9 |            0.00% | > |                       real/gg ||  |     2.654e9 |            0.00% | > |                     real/grep ||  |     4.623e9 |            0.00% | > |                   real/hidden ||  |     5.100e9 |            0.00% | > |                      real/hpg ||  |     3.160e9 |           -0.10% | > |                    real/infer ||  |     1.731e9 |            0.00% | > |                     real/lift ||  |     2.761e9 |            0.00% | > |                   real/linear ||  |     5.412e9 |           -0.07% | > |                 real/maillist ||  |     3.331e9 |            0.00% | > |                  real/mkhprog ||  | 9748392.000 |            0.00% | > |                   real/parser ||  |     2.666e9 |            0.00% | > |                      real/pic ||  |     1.469e9 |            0.00% | > |                   real/prolog ||  |     2.922e9 |           -0.02% | > |                  real/reptile ||  |     5.121e9 |            0.00% | > |                      real/rsa ||  |     8.414e8 |            0.00% | > |                      real/scs ||  |     4.044e9 |            0.00% | > |                  real/smallpt ||  |     2.874e9 |            0.00% | > |                   real/symalg ||  |     3.195e8 |            0.00% | > |                  real/veritas ||  |     4.172e9 |            0.00% | > |         shootout/binary-trees ||  |     4.300e9 |            0.00% | > |       shootout/fannkuch-redux ||  |   69144.000 |           -0.03% | > |                shootout/fasta ||  |     1.718e9 |           +0.00% | > |         shootout/k-nucleotide ||  |     7.081e7 |           +0.00% | > |               shootout/n-body ||  |  130608.000 |            0.00% | > |             shootout/pidigits ||  |    1.027e10 |            0.00% | > |   shootout/reverse-complement ||  |   59768.000 |            0.00% | > |        shootout/spectral-norm ||  |  178112.000 |            0.00% | > |               smp/callback001 ||  |     1.114e9 |            0.00% | > |               smp/callback002 ||  |     3.264e9 |            0.00% | > |                      smp/chan ||  |     1.240e9 |            0.00% | > |                     smp/sieve ||  |     1.410e9 |            0.00% | > |                smp/threads001 ||  |    1.072e10 |            0.00% | > |                smp/threads003 ||  |     3.051e8 |           -0.01% | > |                smp/threads006 ||  |     2.242e8 |            0.00% | > |                smp/threads007 ||  |     1.778e9 |           -0.00% | > |                 spectral/ansi ||  |     6.713e9 |            0.00% | > |                 spectral/atom ||  |     3.580e9 |            0.00% | > |               spectral/awards ||  |     4.759e9 |            0.00% | > |               spectral/banner ||  |     6.156e9 |            0.00% | > |                spectral/boyer ||  |     4.665e9 |            0.00% | > |               spectral/boyer2 ||  |     1.153e9 |            0.00% | > |             spectral/calendar ||  |     7.102e9 |            0.00% | > |             spectral/cichelli ||  |     1.969e9 |            0.00% | > |              spectral/circsim ||  |     4.850e9 |            0.00% | > |             spectral/clausify ||  |     2.095e9 |            0.00% | > |          spectral/constraints ||  |     4.872e9 |            0.00% | > |         spectral/cryptarithm1 ||  |     5.981e9 |            0.00% | > |         spectral/cryptarithm2 ||  |     3.663e9 |            0.00% | > |                  spectral/cse ||  |     3.802e9 |            0.00% | > |               spectral/dom-lt ||  |     3.890e9 |            0.00% | > |                spectral/eliza ||  |     4.102e9 |           +0.00% | > |          spectral/exact-reals ||  |     9.584e8 |           -0.00% | > |               spectral/expert ||  |     2.090e9 |            0.00% | > |                 spectral/fft2 ||  |     1.431e9 |           -0.22% | > |             spectral/fibheaps ||  |     4.737e9 |            0.00% | > |                 spectral/fish ||  |     6.193e9 |            0.00% | > |                  spectral/gcd ||  |     2.069e9 |            0.00% | > | spectral/hartel/comp_lab_zift ||  |     4.740e9 |            0.00% | > |         spectral/hartel/event ||  |     3.635e9 |          -12.13% | > |           spectral/hartel/fft ||  |     1.611e9 |            0.00% | > |        spectral/hartel/genfft ||  |     8.020e9 |            0.00% | > |           spectral/hartel/ida ||  |     3.515e9 |            0.00% | > |     spectral/hartel/listcompr ||  |     6.157e9 |            0.00% | > |      spectral/hartel/listcopy ||  |     6.758e9 |            0.00% | > |      spectral/hartel/nucleic2 ||  |     2.965e9 |            0.00% | > |       spectral/hartel/parstof ||  |     1.368e9 |            0.00% | > |         spectral/hartel/sched ||  |     3.675e9 |            0.00% | > |         spectral/hartel/solid ||  |     3.509e9 |            0.00% | > |     spectral/hartel/transform ||  |     3.959e9 |            0.00% | > |     spectral/hartel/typecheck ||  |     2.570e9 |            0.00% | > |          spectral/hartel/wang ||  |     4.735e9 |            0.00% | > |     spectral/hartel/wave4main ||  |     1.147e9 |            0.00% | > |              spectral/integer ||  |     3.260e9 |            0.00% | > |              spectral/knights ||  |     1.094e9 |            0.00% | > |               spectral/lambda ||  |     2.950e9 |            0.00% | > |           spectral/last-piece ||  |     6.852e8 |            0.00% | > |                 spectral/lcss ||  |     6.565e9 |            0.00% | > |                 spectral/life ||  |     6.799e9 |            0.00% | > |               spectral/mandel ||  |     1.972e9 |            0.00% | > |              spectral/mandel2 ||  |     5.231e8 |            0.00% | > |                 spectral/mate ||  |     4.598e9 |            0.00% | > |              spectral/minimax ||  |     2.683e9 |            0.00% | > |           spectral/multiplier ||  |     2.850e9 |            0.00% | > |                 spectral/para ||  |     4.056e9 |            0.00% | > |                spectral/power ||  |     1.428e9 |            0.00% | > |               spectral/pretty ||  |  136880.000 |           -0.11% | > |            spectral/primetest ||  |     8.455e8 |            0.00% | > |               spectral/puzzle ||  |     1.809e9 |            0.00% | > |              spectral/rewrite ||  |     1.694e9 |            0.00% | > |                  spectral/scc ||  |   58280.000 |            0.00% | > |               spectral/simple ||  |     2.316e9 |            0.00% | > |              spectral/sorting ||  |     3.078e9 |            0.00% | > |               spectral/sphere ||  |     2.298e9 |            0.00% | > |             spectral/treejoin ||  |     2.796e9 |            0.00% | > +===============================++==+=============+==================+ > |                     geom mean ||  |      -0.12% |                  | > +-------------------------------++--+-------------+------------------+ > > # instructions > > +-------------------------------++--+------------+------------------+ > |                               ||  |    master/ | callstack/ (rel) | > +===============================++==+============+==================+ > |          imaginary/bernouilli ||  |    7.057e9 |           +0.00% | > |        imaginary/digits-of-e1 ||  |    5.549e9 |           -0.00% | > |        imaginary/digits-of-e2 ||  |    5.555e9 |           -0.01% | > |              imaginary/exp3_8 ||  |    8.779e9 |           +0.03% | > |         imaginary/gen_regexps ||  |    8.650e9 |           -0.00% | > |           imaginary/integrate ||  |    6.276e9 |           +0.00% | > |               imaginary/kahan ||  |    6.707e9 |           +0.00% | > |           imaginary/paraffins ||  |    8.089e9 |           -0.00% | > |              imaginary/primes ||  |    8.278e9 |           +0.01% | > |              imaginary/queens ||  |   1.010e10 |           -0.00% | > |                imaginary/rfib ||  |    5.299e9 |           +0.00% | > |                 imaginary/tak ||  |    5.867e9 |           +0.00% | > |        imaginary/wheel-sieve1 ||  |    6.615e9 |           +0.04% | > |        imaginary/wheel-sieve2 ||  |    6.286e9 |           +0.02% | > |                imaginary/x2n1 ||  |    7.452e9 |           +0.00% | > |         parallel/blackscholes ||  |    8.022e9 |           +0.00% | > |                parallel/coins ||  |   1.149e10 |           +0.00% | > |                 parallel/gray ||  |    6.141e9 |           +0.14% | > |               parallel/mandel ||  |   3.288e10 |           -0.01% | > |              parallel/matmult ||  |   1.115e10 |           -0.00% | > |              parallel/minimax ||  |   3.863e10 |           -0.08% | > |                parallel/nbody ||  |    7.939e8 |           +0.00% | > |               parallel/parfib ||  |   2.231e10 |           +0.00% | > |              parallel/partree ||  |    7.347e9 |           +0.01% | > |                 parallel/prsa ||  |   1.811e10 |           -0.00% | > |               parallel/queens ||  |   1.037e10 |           +0.00% | > |                  parallel/ray ||  |   1.299e10 |           +0.00% | > |             parallel/sumeuler ||  |    3.483e9 |           +0.00% | > |            parallel/transclos ||  |   1.982e10 |           +0.00% | > |                     real/anna ||  |    5.343e9 |           +0.05% | > |             real/ben-raytrace ||  |   1.215e11 |           +0.00% | > |                     real/bspt ||  |    9.226e9 |           -0.00% | > |                real/cacheprof ||  |    6.763e9 |           +0.02% | > |                 real/compress ||  |    5.820e9 |           -0.00% | > |                real/compress2 ||  |    4.569e9 |           +0.00% | > |                   real/eff/CS ||  |    7.758e8 |           +0.00% | > |                  real/eff/CSD ||  |    3.745e9 |           +0.00% | > |                   real/eff/FS ||  |    2.799e9 |           +0.00% | > |                    real/eff/S ||  |    4.334e9 |           +0.00% | > |                   real/eff/VS ||  |    2.221e9 |           +0.01% | > |                  real/eff/VSD ||  |    8.075e7 |           +0.00% | > |                  real/eff/VSM ||  |    9.635e8 |           +0.00% | > |                      real/fem ||  |    6.649e9 |           -0.64% | > |                    real/fluid ||  |    3.904e9 |           -0.00% | > |                   real/fulsom ||  |    2.490e9 |           +0.00% | > |                   real/gamteb ||  |   1.013e10 |           +0.01% | > |                       real/gg ||  |    7.253e9 |           +0.01% | > |                     real/grep ||  |    7.546e9 |           +0.00% | > |                   real/hidden ||  |    7.198e9 |           +1.64% | > |                      real/hpg ||  |    4.966e9 |           +0.88% | > |                    real/infer ||  |    8.318e9 |           +0.00% | > |                     real/lift ||  |    4.430e9 |           -0.00% | > |                   real/linear ||  |    8.436e9 |           +1.97% | > |                 real/maillist ||  |    1.974e9 |           +0.05% | > |                  real/mkhprog ||  |    2.249e7 |           +0.00% | > |                   real/parser ||  |    5.178e9 |           -0.00% | > |                      real/pic ||  |    3.268e9 |           -0.00% | > |                   real/prolog ||  |    5.742e9 |           +0.01% | > |                  real/reptile ||  |    6.046e9 |           +0.00% | > |                      real/rsa ||  |    7.191e9 |           +0.00% | > |                      real/scs ||  |    6.174e9 |           +0.00% | > |                  real/smallpt ||  |   1.128e10 |           +0.00% | > |                   real/symalg ||  |    8.230e9 |           +0.00% | > |                  real/veritas ||  |    4.832e9 |           -0.01% | > |         shootout/binary-trees ||  |   1.073e10 |           +0.01% | > |       shootout/fannkuch-redux ||  |   1.909e10 |           -0.00% | > |                shootout/fasta ||  |    4.189e9 |           +0.00% | > |         shootout/k-nucleotide ||  |    4.219e9 |           +0.01% | > |               shootout/n-body ||  |    3.721e9 |           +0.00% | > |             shootout/pidigits ||  |    8.084e9 |           +0.00% | > |   shootout/reverse-complement ||  | 781364.000 |           +0.51% | > |        shootout/spectral-norm ||  |    4.252e9 |           +0.00% | > |               smp/callback001 ||  |    1.573e9 |           +0.01% | > |               smp/callback002 ||  |    2.621e9 |           +0.00% | > |                      smp/chan ||  |    8.718e9 |           +2.56% | > |                     smp/sieve ||  |    5.538e9 |           -0.87% | > |                smp/threads001 ||  |    5.139e9 |           -0.00% | > |                smp/threads003 ||  |    2.903e9 |           -0.05% | > |                smp/threads006 ||  |    7.402e8 |           +0.01% | > |                smp/threads007 ||  |    4.090e9 |           -0.00% | > |                 spectral/ansi ||  |    5.961e9 |           -0.00% | > |                 spectral/atom ||  |    5.861e9 |           +0.01% | > |               spectral/awards ||  |    8.744e9 |           +0.00% | > |               spectral/banner ||  |    8.824e9 |           +0.23% | > |                spectral/boyer ||  |    7.657e9 |           -0.00% | > |               spectral/boyer2 ||  |    8.881e9 |           -0.00% | > |             spectral/calendar ||  |    7.546e9 |           -0.00% | > |             spectral/cichelli ||  |    8.625e9 |           +0.01% | > |              spectral/circsim ||  |    6.850e9 |           +0.00% | > |             spectral/clausify ||  |    6.223e9 |           -0.00% | > |          spectral/constraints ||  |    8.314e9 |           +0.14% | > |         spectral/cryptarithm1 ||  |    7.787e9 |           -0.00% | > |         spectral/cryptarithm2 ||  |    6.761e9 |           +0.00% | > |                  spectral/cse ||  |    6.358e9 |           -0.00% | > |               spectral/dom-lt ||  |    7.774e9 |           -0.00% | > |                spectral/eliza ||  |    8.273e9 |           +0.00% | > |          spectral/exact-reals ||  |    5.597e9 |           +0.01% | > |               spectral/expert ||  |    5.087e9 |           +0.04% | > |                 spectral/fft2 ||  |    8.831e9 |           +0.31% | > |             spectral/fibheaps ||  |    8.011e9 |           -0.00% | > |                 spectral/fish ||  |    7.314e9 |           -0.00% | > |                  spectral/gcd ||  |    6.386e9 |           -0.00% | > | spectral/hartel/comp_lab_zift ||  |    8.717e9 |           -0.00% | > |         spectral/hartel/event ||  |    9.071e9 |           -2.06% | > |           spectral/hartel/fft ||  |    3.239e9 |           +0.00% | > |        spectral/hartel/genfft ||  |   1.020e10 |           +0.00% | > |           spectral/hartel/ida ||  |    5.413e9 |           -0.30% | > |     spectral/hartel/listcompr ||  |    6.142e9 |           +0.02% | > |      spectral/hartel/listcopy ||  |    6.757e9 |           +0.02% | > |      spectral/hartel/nucleic2 ||  |    4.402e9 |           +0.00% | > |       spectral/hartel/parstof ||  |    5.555e9 |           -0.00% | > |         spectral/hartel/sched ||  |    5.800e9 |           +0.00% | > |         spectral/hartel/solid ||  |    5.845e9 |           +0.24% | > |     spectral/hartel/transform ||  |    5.709e9 |           -0.00% | > |     spectral/hartel/typecheck ||  |    5.841e9 |           +0.00% | > |          spectral/hartel/wang ||  |    8.731e9 |           +0.12% | > |     spectral/hartel/wave4main ||  |    6.024e9 |           -0.00% | > |              spectral/integer ||  |    7.068e9 |           -0.00% | > |              spectral/knights ||  |    8.294e9 |           -0.00% | > |               spectral/lambda ||  |    8.081e9 |           +0.00% | > |           spectral/last-piece ||  |    1.878e9 |           +0.00% | > |                 spectral/lcss ||  |    8.761e9 |           -0.00% | > |                 spectral/life ||  |    9.136e9 |           -0.00% | > |               spectral/mandel ||  |    7.037e9 |           +0.00% | > |              spectral/mandel2 ||  |    3.957e9 |           +0.00% | > |                 spectral/mate ||  |    7.565e9 |           +0.01% | > |              spectral/minimax ||  |    8.649e9 |           -0.00% | > |           spectral/multiplier ||  |    6.096e9 |           +0.00% | > |                 spectral/para ||  |    6.561e9 |           +0.00% | > |                spectral/power ||  |    6.749e9 |           -0.00% | > |               spectral/pretty ||  | 851224.000 |           +0.17% | > |            spectral/primetest ||  |    7.391e9 |           -0.00% | > |               spectral/puzzle ||  |    6.401e9 |           +0.00% | > |              spectral/rewrite ||  |    5.553e9 |           +0.67% | > |                  spectral/scc ||  | 774059.000 |           +0.49% | > |               spectral/simple ||  |   1.214e10 |           +0.01% | > |              spectral/sorting ||  |    9.074e9 |           -0.00% | > |               spectral/sphere ||  |    5.371e9 |           -0.00% | > |             spectral/treejoin ||  |    9.768e9 |           +0.00% | > +===============================++==+============+==================+ > |                     geom mean ||  |     +0.05% |                  | > +-------------------------------++--+------------+------------------+ > > > > # LLC cache misses > > +-------------------------------++--+-------------+------------------+ > |                               ||  |     master/ | callstack/ (rel) | > +===============================++==+=============+==================+ > |          imaginary/bernouilli ||  |    4964.000 |           +1.37% | > |        imaginary/digits-of-e1 ||  |    4863.000 |           -0.35% | > |        imaginary/digits-of-e2 ||  |    4958.000 |           +1.63% | > |              imaginary/exp3_8 ||  |    4513.000 |           +0.42% | > |         imaginary/gen_regexps ||  |    4535.000 |           +0.09% | > |           imaginary/integrate ||  |    4733.000 |           +1.08% | > |               imaginary/kahan ||  |    4447.000 |           -0.13% | > |           imaginary/paraffins ||  |    4826.000 |           -0.08% | > |              imaginary/primes ||  |    4876.000 |           +0.94% | > |              imaginary/queens ||  |    4541.000 |           -0.07% | > |                imaginary/rfib ||  |    4485.000 |           -0.13% | > |                 imaginary/tak ||  |    4461.000 |           +0.25% | > |        imaginary/wheel-sieve1 ||  |    4865.000 |           +1.29% | > |        imaginary/wheel-sieve2 ||  |    4893.000 |           +1.25% | > |                imaginary/x2n1 ||  |    4630.000 |           +0.22% | > |         parallel/blackscholes ||  |   12862.000 |           +0.30% | > |                parallel/coins ||  | 6455583.000 |           +0.00% | > |                 parallel/gray ||  |    6372.000 |           +1.77% | > |               parallel/mandel ||  |  852468.000 |           -0.02% | > |              parallel/matmult ||  |    4615.000 |           -0.30% | > |              parallel/minimax ||  |    4617.000 |           +0.84% | > |                parallel/nbody ||  |    4455.000 |           -0.04% | > |               parallel/parfib ||  |    4528.000 |           +0.22% | > |              parallel/partree ||  |    4627.000 |           +0.43% | > |                 parallel/prsa ||  |    4619.000 |           +0.54% | > |               parallel/queens ||  |    4528.000 |           +1.37% | > |                  parallel/ray ||  |    4626.000 |           +0.35% | > |             parallel/sumeuler ||  |    4446.000 |           +0.13% | > |            parallel/transclos ||  |    4741.000 |           -0.17% | > |                     real/anna ||  |    6443.000 |           +5.34% | > |             real/ben-raytrace ||  |    6819.000 |           -0.13% | > |                     real/bspt ||  |    5195.000 |           -0.21% | > |                real/cacheprof ||  |    6734.000 |           +1.62% | > |                 real/compress ||  |    4914.000 |           +0.53% | > |                real/compress2 ||  |    4783.000 |           -0.25% | > |                   real/eff/CS ||  |    4439.000 |           +0.38% | > |                  real/eff/CSD ||  |    4446.000 |            0.00% | > |                   real/eff/FS ||  |    4451.000 |           -0.04% | > |                    real/eff/S ||  | 5619842.000 |           -0.00% | > |                   real/eff/VS ||  | 1254362.000 |           +0.00% | > |                  real/eff/VSD ||  |    4403.000 |           -0.43% | > |                  real/eff/VSM ||  |    4445.000 |           -0.11% | > |                      real/fem ||  |    4967.000 |           +2.07% | > |                    real/fluid ||  |    6117.000 |           +0.85% | > |                   real/fulsom ||  |    5060.000 |           -0.10% | > |                   real/gamteb ||  |    5615.000 |           +0.64% | > |                       real/gg ||  |    5242.000 |           +0.88% | > |                     real/grep ||  |    4866.000 |           +0.62% | > |                   real/hidden ||  |    5576.000 |           +2.06% | > |                      real/hpg ||  |    5614.000 |           +2.92% | > |                    real/infer ||  |    4833.000 |           -0.14% | > |                     real/lift ||  |    4809.000 |           +1.48% | > |                   real/linear ||  |    5368.000 |           +4.53% | > |                 real/maillist ||  |   12942.000 |           +0.32% | > |                  real/mkhprog ||  |    4483.000 |           +0.20% | > |                   real/parser ||  |    5309.000 |           +1.64% | > |                      real/pic ||  |    4937.000 |           +0.81% | > |                   real/prolog ||  |    4843.000 |           +1.03% | > |                  real/reptile ||  |    5548.000 |           -0.43% | > |                      real/rsa ||  |    4667.000 |           +0.26% | > |                      real/scs ||  |    5667.000 |           +1.48% | > |                  real/smallpt ||  |    5836.000 |           +1.29% | > |                   real/symalg ||  |    5422.000 |           +0.30% | > |                  real/veritas ||  |    6984.000 |           +2.61% | > |         shootout/binary-trees ||  |    5079.000 |           +0.73% | > |       shootout/fannkuch-redux ||  |    4478.000 |           -0.51% | > |                shootout/fasta ||  |    4625.000 |           -0.13% | > |         shootout/k-nucleotide ||  | 1161663.000 |           -2.58% | > |               shootout/n-body ||  |    4512.000 |           +0.04% | > |             shootout/pidigits ||  |    4651.000 |           -0.39% | > |   shootout/reverse-complement ||  |    4416.000 |            0.00% | > |        shootout/spectral-norm ||  |    4477.000 |           +0.25% | > |               smp/callback001 ||  |  488453.000 |           -0.01% | > |               smp/callback002 ||  |    4513.000 |           -0.11% | > |                      smp/chan ||  |     1.110e7 |           +7.03% | > |                     smp/sieve ||  |    4555.000 |           +0.72% | > |                smp/threads001 ||  |    4481.000 |           +0.49% | > |                smp/threads003 ||  |   83898.000 |           -1.63% | > |                smp/threads006 ||  | 1804659.000 |           +0.49% | > |                smp/threads007 ||  | 2427701.000 |           -0.24% | > |                 spectral/ansi ||  |    4759.000 |           +0.27% | > |                 spectral/atom ||  |    4691.000 |           +0.62% | > |               spectral/awards ||  |    4717.000 |           +1.14% | > |               spectral/banner ||  |    5056.000 |           +1.21% | > |                spectral/boyer ||  |    5045.000 |           +0.06% | > |               spectral/boyer2 ||  |    4832.000 |           -0.04% | > |             spectral/calendar ||  |    4622.000 |           +0.74% | > |             spectral/cichelli ||  |    4728.000 |           +1.67% | > |              spectral/circsim ||  |   40269.000 |           -1.55% | > |             spectral/clausify ||  |    4835.000 |           -0.17% | > |          spectral/constraints ||  |    4871.000 |           +1.44% | > |         spectral/cryptarithm1 ||  |    4562.000 |           +0.18% | > |         spectral/cryptarithm2 ||  |    4600.000 |           +0.07% | > |                  spectral/cse ||  |    4534.000 |           +0.33% | > |               spectral/dom-lt ||  |    5179.000 |           +0.10% | > |                spectral/eliza ||  |    4968.000 |           +0.34% | > |          spectral/exact-reals ||  |    4840.000 |           +1.34% | > |               spectral/expert ||  |    4770.000 |           +2.81% | > |                 spectral/fft2 ||  |    5296.000 |           +1.91% | > |             spectral/fibheaps ||  |    4858.000 |           +0.02% | > |                 spectral/fish ||  |    4687.000 |           +0.04% | > |                  spectral/gcd ||  |    4575.000 |           +0.22% | > | spectral/hartel/comp_lab_zift ||  |    4960.000 |           +0.58% | > |         spectral/hartel/event ||  |    4875.000 |           +0.96% | > |           spectral/hartel/fft ||  |    5121.000 |           +0.70% | > |        spectral/hartel/genfft ||  |    4875.000 |           +0.04% | > |           spectral/hartel/ida ||  |    4877.000 |           +0.84% | > |     spectral/hartel/listcompr ||  |    4651.000 |           +1.76% | > |      spectral/hartel/listcopy ||  |    4649.000 |           +1.96% | > |      spectral/hartel/nucleic2 ||  |    5998.000 |           +0.68% | > |       spectral/hartel/parstof ||  |    5583.000 |           -0.05% | > |         spectral/hartel/sched ||  |    4856.000 |           -0.23% | > |         spectral/hartel/solid ||  |    5282.000 |           +1.21% | > |     spectral/hartel/transform ||  |    4875.000 |           +1.56% | > |     spectral/hartel/typecheck ||  |    4724.000 |           +0.95% | > |          spectral/hartel/wang ||  |    4993.000 |           +2.38% | > |     spectral/hartel/wave4main ||  |    4877.000 |           -0.04% | > |              spectral/integer ||  |    4619.000 |           -0.13% | > |              spectral/knights ||  |    4694.000 |           +0.58% | > |               spectral/lambda ||  |    4984.000 |           +0.66% | > |           spectral/last-piece ||  |    4869.000 |           -0.21% | > |                 spectral/lcss ||  |    4876.000 |           +0.04% | > |                 spectral/life ||  |    4884.000 |           +1.29% | > |               spectral/mandel ||  |    4900.000 |           +0.16% | > |              spectral/mandel2 ||  |    4479.000 |           -0.13% | > |                 spectral/mate ||  |    5086.000 |           +1.83% | > |              spectral/minimax ||  |    4605.000 |           -0.04% | > |           spectral/multiplier ||  |    4672.000 |           +0.98% | > |                 spectral/para ||  |    4935.000 |           +0.83% | > |                spectral/power ||  |    4918.000 |           +0.18% | > |               spectral/pretty ||  |    4432.000 |           +0.14% | > |            spectral/primetest ||  |    5021.000 |           -0.04% | > |               spectral/puzzle ||  |    4603.000 |           +0.04% | > |              spectral/rewrite ||  |    4618.000 |           +0.97% | > |                  spectral/scc ||  |    4415.000 |           +0.34% | > |               spectral/simple ||  | 2413361.000 |           -1.18% | > |              spectral/sorting ||  |    5357.000 |           -1.55% | > |               spectral/sphere ||  |    5717.000 |           +0.84% | > |             spectral/treejoin ||  |    5130.000 |           +0.02% | > +===============================++==+=============+==================+ > |                     geom mean ||  |      +0.58% |                  | > +-------------------------------++--+-------------+------------------+ > > > > # L1 cache misses > > +-------------------------------++--+-------------+------------------+ > |                               ||  |     master/ | callstack/ (rel) | > +===============================++==+=============+==================+ > |          imaginary/bernouilli ||  |     4.235e7 |           +0.13% | > |        imaginary/digits-of-e1 ||  | 3708507.000 |           -0.06% | > |        imaginary/digits-of-e2 ||  |     2.913e7 |           -0.16% | > |              imaginary/exp3_8 ||  |     1.881e8 |           -0.07% | > |         imaginary/gen_regexps ||  |     2.915e7 |           -0.05% | > |           imaginary/integrate ||  | 1341520.000 |           -4.99% | > |               imaginary/kahan ||  |    7577.000 |           +0.15% | > |           imaginary/paraffins ||  |     5.994e7 |           -0.02% | > |              imaginary/primes ||  |     1.165e8 |           -0.01% | > |              imaginary/queens ||  |  315321.000 |           -0.94% | > |                imaginary/rfib ||  |    7833.000 |           -0.46% | > |                 imaginary/tak ||  |    7688.000 |           +0.03% | > |        imaginary/wheel-sieve1 ||  | 7508229.000 |           +0.51% | > |        imaginary/wheel-sieve2 ||  |     4.338e7 |           -0.02% | > |                imaginary/x2n1 ||  |  129793.000 |           +0.50% | > |         parallel/blackscholes ||  |     1.550e7 |           -0.16% | > |                parallel/coins ||  |     3.952e7 |           +0.26% | > |                 parallel/gray ||  |     1.736e7 |           +1.38% | > |               parallel/mandel ||  |     1.356e7 |           +0.20% | > |              parallel/matmult ||  |     5.267e8 |           -0.01% | > |              parallel/minimax ||  |     1.140e8 |           -0.14% | > |                parallel/nbody ||  |     1.248e7 |           -0.02% | > |               parallel/parfib ||  |  252463.000 |           +6.49% | > |              parallel/partree ||  |     5.642e7 |           +0.08% | > |                 parallel/prsa ||  | 5700667.000 |           +0.27% | > |               parallel/queens ||  | 3129546.000 |           +0.19% | > |                  parallel/ray ||  |     1.260e7 |           +4.27% | > |             parallel/sumeuler ||  |   35221.000 |           -0.07% | > |            parallel/transclos ||  |     1.863e7 |           +0.17% | > |                     real/anna ||  |     3.737e7 |           +0.10% | > |             real/ben-raytrace ||  |     6.695e7 |           +0.59% | > |                     real/bspt ||  |     1.492e8 |           +0.01% | > |                real/cacheprof ||  |     5.661e7 |           -0.24% | > |                 real/compress ||  |     3.247e7 |           -2.71% | > |                real/compress2 ||  |     2.717e7 |           +0.13% | > |                   real/eff/CS ||  |   54141.000 |           -0.28% | > |                  real/eff/CSD ||  |  532877.000 |           -0.07% | > |                   real/eff/FS ||  |  512883.000 |           +0.18% | > |                    real/eff/S ||  |     1.412e7 |           -0.07% | > |                   real/eff/VS ||  | 6730192.000 |           -0.42% | > |                  real/eff/VSD ||  |    7449.000 |           -0.30% | > |                  real/eff/VSM ||  |  121912.000 |           -0.22% | > |                      real/fem ||  |     3.841e7 |           +6.86% | > |                    real/fluid ||  |     1.579e7 |           +0.91% | > |                   real/fulsom ||  |     1.036e7 |           +0.03% | > |                   real/gamteb ||  |     3.473e7 |           -0.02% | > |                       real/gg ||  |     7.439e7 |           +0.09% | > |                     real/grep ||  |     7.940e7 |           +0.08% | > |                   real/hidden ||  |     1.074e7 |           +0.20% | > |                      real/hpg ||  |     1.757e7 |           +0.32% | > |                    real/infer ||  |     2.006e8 |           -0.02% | > |                     real/lift ||  |     2.741e7 |           +0.20% | > |                   real/linear ||  |     8.899e7 |           +1.27% | > |                 real/maillist ||  | 9646364.000 |           -0.06% | > |                  real/mkhprog ||  |   11950.000 |           +3.72% | > |                   real/parser ||  |     1.269e7 |           +0.92% | > |                      real/pic ||  |     4.450e7 |           -0.24% | > |                   real/prolog ||  |     2.973e7 |           -0.34% | > |                  real/reptile ||  |     1.945e7 |           -0.07% | > |                      real/rsa ||  | 1310283.000 |           -0.18% | > |                      real/scs ||  |     1.916e7 |           +0.06% | > |                  real/smallpt ||  | 7088127.000 |           +0.47% | > |                   real/symalg ||  | 5981494.000 |           -0.11% | > |                  real/veritas ||  |     1.860e7 |           -1.22% | > |         shootout/binary-trees ||  |     3.661e7 |           +0.01% | > |       shootout/fannkuch-redux ||  |    7741.000 |           -0.62% | > |                shootout/fasta ||  |     5.215e7 |           +0.01% | > |         shootout/k-nucleotide ||  |     1.247e7 |           +0.01% | > |               shootout/n-body ||  |    8025.000 |           +0.04% | > |             shootout/pidigits ||  |     2.316e8 |           +0.02% | > |   shootout/reverse-complement ||  |    7627.000 |           -0.20% | > |        shootout/spectral-norm ||  |   21764.000 |           +0.23% | > |               smp/callback001 ||  | 5824201.000 |           +0.07% | > |               smp/callback002 ||  | 8288204.000 |           -0.09% | > |                      smp/chan ||  |     2.846e7 |           +2.62% | > |                     smp/sieve ||  |     5.400e7 |           -1.10% | > |                smp/threads001 ||  |     2.312e7 |           +0.45% | > |                smp/threads003 ||  |     4.773e7 |           -0.22% | > |                smp/threads006 ||  | 9331792.000 |           +0.02% | > |                smp/threads007 ||  |     2.721e7 |           +0.36% | > |                 spectral/ansi ||  |     6.940e7 |           -0.01% | > |                 spectral/atom ||  |     1.248e8 |           +0.01% | > |               spectral/awards ||  | 7810137.000 |           -1.82% | > |               spectral/banner ||  |     3.727e7 |           +2.57% | > |                spectral/boyer ||  |     2.284e7 |           -0.19% | > |               spectral/boyer2 ||  |     3.926e7 |           -0.63% | > |             spectral/calendar ||  | 7366268.000 |           -0.91% | > |             spectral/cichelli ||  |     1.797e7 |           +0.02% | > |              spectral/circsim ||  |     9.138e7 |           +0.07% | > |             spectral/clausify ||  | 6134801.000 |           -0.11% | > |          spectral/constraints ||  |     2.950e7 |           +0.38% | > |         spectral/cryptarithm1 ||  | 3139494.000 |           +0.08% | > |         spectral/cryptarithm2 ||  | 3481535.000 |           +0.35% | > |                  spectral/cse ||  | 4798864.000 |           -7.01% | > |               spectral/dom-lt ||  |     2.556e7 |           -0.11% | > |                spectral/eliza ||  |     1.921e7 |           +1.14% | > |          spectral/exact-reals ||  | 2391927.000 |           +1.24% | > |               spectral/expert ||  |     2.311e7 |           -0.08% | > |                 spectral/fft2 ||  |     1.917e8 |           +0.81% | > |             spectral/fibheaps ||  |     5.236e7 |           -0.06% | > |                 spectral/fish ||  | 8017906.000 |           +0.13% | > |                  spectral/gcd ||  | 1652038.000 |           +0.07% | > | spectral/hartel/comp_lab_zift ||  |     6.167e7 |           -0.11% | > |         spectral/hartel/event ||  |     4.857e7 |           -2.47% | > |           spectral/hartel/fft ||  |     3.723e7 |           -0.04% | > |        spectral/hartel/genfft ||  |     2.201e7 |           +1.31% | > |           spectral/hartel/ida ||  |     1.316e7 |           +0.16% | > |     spectral/hartel/listcompr ||  | 9143834.000 |           +1.54% | > |      spectral/hartel/listcopy ||  |     1.018e7 |           +2.27% | > |      spectral/hartel/nucleic2 ||  |     1.035e7 |           -2.83% | > |       spectral/hartel/parstof ||  |     2.290e7 |           -2.36% | > |         spectral/hartel/sched ||  | 6090930.000 |           -0.15% | > |         spectral/hartel/solid ||  |     3.408e7 |           +0.00% | > |     spectral/hartel/transform ||  |     2.255e7 |           +0.25% | > |     spectral/hartel/typecheck ||  |     1.447e7 |           -1.37% | > |          spectral/hartel/wang ||  |     1.089e8 |           +0.19% | > |     spectral/hartel/wave4main ||  |     8.229e7 |           +0.29% | > |              spectral/integer ||  | 1101168.000 |           -0.06% | > |              spectral/knights ||  |     3.424e7 |           +0.92% | > |               spectral/lambda ||  |     6.667e7 |           +0.14% | > |           spectral/last-piece ||  | 3620219.000 |           -0.43% | > |                 spectral/lcss ||  |     7.252e7 |           -0.26% | > |                 spectral/life ||  |     1.231e8 |           -0.11% | > |               spectral/mandel ||  |  741678.000 |           +0.09% | > |              spectral/mandel2 ||  |  311375.000 |           +0.79% | > |                 spectral/mate ||  | 4858523.000 |           -1.23% | > |              spectral/minimax ||  | 1172869.000 |           +0.51% | > |           spectral/multiplier ||  |     1.060e8 |           +0.03% | > |                 spectral/para ||  |     5.089e7 |           +0.15% | > |                spectral/power ||  |     4.488e7 |           -0.00% | > |               spectral/pretty ||  |    7649.000 |           +0.38% | > |            spectral/primetest ||  |  500918.000 |           +1.32% | > |               spectral/puzzle ||  | 3210919.000 |           -0.09% | > |              spectral/rewrite ||  |  825290.000 |           -7.73% | > |                  spectral/scc ||  |    7483.000 |           +0.16% | > |               spectral/simple ||  |     8.786e7 |           +0.01% | > |              spectral/sorting ||  |     1.261e8 |           -0.02% | > |               spectral/sphere ||  | 4854033.000 |           +0.43% | > |             spectral/treejoin ||  |     8.455e7 |           +0.03% | > +===============================++==+=============+==================+ > |                     geom mean ||  |      +0.03% |                  | > +-------------------------------++--+-------------+------------------+ > > > # perf instructions > > +-------------------------------++--+-------------+------------------+ > |                               ||  |     master/ | callstack/ (rel) | > +===============================++==+=============+==================+ > |          imaginary/bernouilli ||  |     7.085e9 |           -0.22% | > |        imaginary/digits-of-e1 ||  |     5.547e9 |           -0.03% | > |        imaginary/digits-of-e2 ||  |     5.549e9 |           -0.06% | > |              imaginary/exp3_8 ||  |     8.785e9 |           -0.06% | > |         imaginary/gen_regexps ||  |     8.650e9 |           -0.04% | > |           imaginary/integrate ||  |     6.260e9 |           +0.20% | > |               imaginary/kahan ||  |     6.699e9 |           +0.16% | > |           imaginary/paraffins ||  |     8.112e9 |           -0.24% | > |              imaginary/primes ||  |     8.244e9 |           -0.24% | > |              imaginary/queens ||  |    1.009e10 |           +0.04% | > |                imaginary/rfib ||  |     5.298e9 |           +0.14% | > |                 imaginary/tak ||  |     5.861e9 |           +0.10% | > |        imaginary/wheel-sieve1 ||  |     6.662e9 |           -0.76% | > |        imaginary/wheel-sieve2 ||  |     6.278e9 |           +0.38% | > |                imaginary/x2n1 ||  |     7.453e9 |           -0.12% | > |         parallel/blackscholes ||  |     8.096e9 |           -0.18% | > |                parallel/coins ||  |    1.194e10 |           -0.03% | > |                 parallel/gray ||  |     6.154e9 |           -0.07% | > |               parallel/mandel ||  |    3.293e10 |           +0.12% | > |              parallel/matmult ||  |    1.118e10 |           +0.06% | > |              parallel/minimax ||  |    3.867e10 |           -0.11% | > |                parallel/nbody ||  |     7.934e8 |           +0.05% | > |               parallel/parfib ||  |    2.232e10 |           -0.01% | > |              parallel/partree ||  |     7.358e9 |           +0.02% | > |                 parallel/prsa ||  |    1.808e10 |           +0.14% | > |               parallel/queens ||  |    1.037e10 |           -0.03% | > |                  parallel/ray ||  |    1.301e10 |           +0.01% | > |             parallel/sumeuler ||  |     3.487e9 |           -0.01% | > |            parallel/transclos ||  |    1.983e10 |           -0.02% | > |                     real/anna ||  |     5.334e9 |           +0.27% | > |             real/ben-raytrace ||  |    1.216e11 |           -0.02% | > |                     real/bspt ||  |     9.224e9 |           -0.05% | > |                real/cacheprof ||  |     6.735e9 |           -0.46% | > |                 real/compress ||  |     5.810e9 |           +0.07% | > |                real/compress2 ||  |     4.580e9 |           -0.21% | > |                   real/eff/CS ||  |     7.582e8 |           +1.19% | > |                  real/eff/CSD ||  |     3.758e9 |           -0.56% | > |                   real/eff/FS ||  |     2.792e9 |           +0.02% | > |                    real/eff/S ||  |     4.760e9 |           -0.60% | > |                   real/eff/VS ||  |     2.285e9 |           +0.20% | > |                  real/eff/VSD ||  |     8.315e7 |           +0.02% | > |                  real/eff/VSM ||  |     9.480e8 |           +1.48% | > |                      real/fem ||  |     6.641e9 |           -0.53% | > |                    real/fluid ||  |     3.914e9 |           +0.00% | > |                   real/fulsom ||  |     2.497e9 |           -0.22% | > |                   real/gamteb ||  |    1.013e10 |           -0.01% | > |                       real/gg ||  |     7.243e9 |           +0.12% | > |                     real/grep ||  |     7.563e9 |           -0.10% | > |                   real/hidden ||  |     7.209e9 |           +1.57% | > |                      real/hpg ||  |     4.982e9 |           +0.91% | > |                    real/infer ||  |     8.312e9 |           +0.11% | > |                     real/lift ||  |     4.441e9 |           -0.18% | > |                   real/linear ||  |     8.438e9 |           +1.90% | > |                 real/maillist ||  |     4.297e9 |           -0.94% | > |                  real/mkhprog ||  |     2.874e7 |           -0.06% | > |                   real/parser ||  |     5.177e9 |           +0.14% | > |                      real/pic ||  |     3.265e9 |           +0.10% | > |                   real/prolog ||  |     5.755e9 |           -0.18% | > |                  real/reptile ||  |     6.050e9 |           +0.07% | > |                      real/rsa ||  |     7.177e9 |           +0.03% | > |                      real/scs ||  |     6.184e9 |           -0.23% | > |                  real/smallpt ||  |    1.129e10 |           -0.16% | > |                   real/symalg ||  |     8.247e9 |           -0.14% | > |                  real/veritas ||  |     4.833e9 |           -0.01% | > |         shootout/binary-trees ||  |    1.071e10 |           +0.12% | > |       shootout/fannkuch-redux ||  |    1.912e10 |           +0.12% | > |                shootout/fasta ||  |     4.273e9 |           -0.50% | > |         shootout/k-nucleotide ||  |     4.227e9 |           -1.34% | > |               shootout/n-body ||  |     3.725e9 |           -0.23% | > |             shootout/pidigits ||  |     8.095e9 |           -0.04% | > |   shootout/reverse-complement ||  | 3245583.000 |           -2.41% | > |        shootout/spectral-norm ||  |     4.238e9 |           -0.15% | > |               smp/callback001 ||  |     1.601e9 |           +0.55% | > |               smp/callback002 ||  |     2.619e9 |           +0.19% | > |                      smp/chan ||  |     7.817e9 |           -0.01% | > |                     smp/sieve ||  |     2.361e9 |           +0.85% | > |                smp/threads001 ||  |     5.145e9 |           +0.17% | > |                smp/threads003 ||  |     2.922e9 |           -0.06% | > |                smp/threads006 ||  |     1.081e9 |           +4.82% | > |                smp/threads007 ||  |     4.328e9 |           +0.63% | > |                 spectral/ansi ||  |     5.961e9 |           +0.21% | > |                 spectral/atom ||  |     5.864e9 |           -0.10% | > |               spectral/awards ||  |     8.749e9 |           -0.02% | > |               spectral/banner ||  |     8.862e9 |           +0.12% | > |                spectral/boyer ||  |     7.669e9 |           -0.09% | > |               spectral/boyer2 ||  |     8.888e9 |           +0.04% | > |             spectral/calendar ||  |     7.541e9 |           +0.13% | > |             spectral/cichelli ||  |     8.675e9 |           -0.17% | > |              spectral/circsim ||  |     6.901e9 |           +0.12% | > |             spectral/clausify ||  |     6.227e9 |           -0.09% | > |          spectral/constraints ||  |     8.308e9 |           +0.36% | > |         spectral/cryptarithm1 ||  |     7.804e9 |           -0.23% | > |         spectral/cryptarithm2 ||  |     6.757e9 |           +0.11% | > |                  spectral/cse ||  |     6.357e9 |           +0.01% | > |               spectral/dom-lt ||  |     7.774e9 |           +0.17% | > |                spectral/eliza ||  |     8.279e9 |           -0.12% | > |          spectral/exact-reals ||  |     5.599e9 |           -0.07% | > |               spectral/expert ||  |     5.096e9 |           -0.09% | > |                 spectral/fft2 ||  |     8.818e9 |           +0.48% | > |             spectral/fibheaps ||  |     8.019e9 |           -0.12% | > |                 spectral/fish ||  |     7.319e9 |           -0.03% | > |                  spectral/gcd ||  |     6.381e9 |           +0.26% | > | spectral/hartel/comp_lab_zift ||  |     8.747e9 |           -0.45% | > |         spectral/hartel/event ||  |     9.153e9 |           -1.50% | > |           spectral/hartel/fft ||  |     3.237e9 |           -0.02% | > |        spectral/hartel/genfft ||  |    1.020e10 |           +0.14% | > |           spectral/hartel/ida ||  |     5.420e9 |           -0.32% | > |     spectral/hartel/listcompr ||  |     6.143e9 |           +0.12% | > |      spectral/hartel/listcopy ||  |     6.759e9 |           +0.01% | > |      spectral/hartel/nucleic2 ||  |     4.413e9 |           -0.67% | > |       spectral/hartel/parstof ||  |     5.552e9 |           +0.04% | > |         spectral/hartel/sched ||  |     5.807e9 |           -0.02% | > |         spectral/hartel/solid ||  |     5.850e9 |           +0.22% | > |     spectral/hartel/transform ||  |     5.713e9 |           -0.01% | > |     spectral/hartel/typecheck ||  |     5.844e9 |           -0.04% | > |          spectral/hartel/wang ||  |     8.727e9 |           +0.29% | > |     spectral/hartel/wave4main ||  |     6.034e9 |           -0.20% | > |              spectral/integer ||  |     7.048e9 |           +0.64% | > |              spectral/knights ||  |     8.310e9 |           -0.08% | > |               spectral/lambda ||  |     8.091e9 |           -0.12% | > |           spectral/last-piece ||  |     1.877e9 |           +0.11% | > |                 spectral/lcss ||  |     8.776e9 |           -0.10% | > |                 spectral/life ||  |     9.143e9 |           -0.05% | > |               spectral/mandel ||  |     7.015e9 |           +0.24% | > |              spectral/mandel2 ||  |     3.957e9 |           +0.03% | > |                 spectral/mate ||  |     7.573e9 |           +0.11% | > |              spectral/minimax ||  |     8.645e9 |           +0.10% | > |           spectral/multiplier ||  |     6.097e9 |           +0.06% | > |                 spectral/para ||  |     6.562e9 |           +0.03% | > |                spectral/power ||  |     6.758e9 |           -0.23% | > |               spectral/pretty ||  | 3371581.000 |           -0.75% | > |            spectral/primetest ||  |     7.409e9 |           -0.04% | > |               spectral/puzzle ||  |     6.405e9 |           -0.19% | > |              spectral/rewrite ||  |     5.558e9 |           +0.62% | > |                  spectral/scc ||  | 3244220.000 |           -1.55% | > |               spectral/simple ||  |    1.220e10 |           +0.25% | > |              spectral/sorting ||  |     9.082e9 |           -0.05% | > |               spectral/sphere ||  |     5.371e9 |           -0.18% | > |             spectral/treejoin ||  |     9.881e9 |           -0.07% | > +===============================++==+=============+==================+ > |                     geom mean ||  |      +0.02% |                  | > +-------------------------------++--+-------------+------------------+ > > > > # perf cycles > > +-------------------------------++--+-------------+------------------+ > |                               ||  |     master/ | callstack/ (rel) | > +===============================++==+=============+==================+ > |          imaginary/bernouilli ||  |     3.726e9 |           +0.96% | > |        imaginary/digits-of-e1 ||  |     2.561e9 |           +3.96% | > |        imaginary/digits-of-e2 ||  |     2.828e9 |           -1.96% | > |              imaginary/exp3_8 ||  |     3.231e9 |           +2.40% | > |         imaginary/gen_regexps ||  |     4.250e9 |           +0.26% | > |           imaginary/integrate ||  |     2.968e9 |           -9.55% | > |               imaginary/kahan ||  |     3.062e9 |           -0.40% | > |           imaginary/paraffins ||  |     3.083e9 |           -1.94% | > |              imaginary/primes ||  |     2.593e9 |           +1.49% | > |              imaginary/queens ||  |     4.713e9 |           -0.75% | > |                imaginary/rfib ||  |     3.942e9 |           -0.09% | > |                 imaginary/tak ||  |     4.385e9 |           -0.60% | > |        imaginary/wheel-sieve1 ||  |     4.582e9 |          -43.27% | > |        imaginary/wheel-sieve2 ||  |     2.563e9 |           -2.37% | > |                imaginary/x2n1 ||  |     2.867e9 |           +0.10% | > |         parallel/blackscholes ||  |     4.854e9 |           -1.40% | > |                parallel/coins ||  |     4.809e9 |           -0.08% | > |                 parallel/gray ||  |     3.600e9 |           +2.96% | > |               parallel/mandel ||  |    1.481e10 |           -1.08% | > |              parallel/matmult ||  |    1.570e10 |           -2.83% | > |              parallel/minimax ||  |    2.420e10 |           +7.85% | > |                parallel/nbody ||  |     4.377e8 |           +1.37% | > |               parallel/parfib ||  |    1.752e10 |           +0.16% | > |              parallel/partree ||  |     3.345e9 |           +2.19% | > |                 parallel/prsa ||  |     7.052e9 |           +6.03% | > |               parallel/queens ||  |     4.686e9 |           +0.06% | > |                  parallel/ray ||  |     9.246e9 |           -2.73% | > |             parallel/sumeuler ||  |     4.166e9 |           -1.20% | > |            parallel/transclos ||  |    1.095e10 |           +1.05% | > |                     real/anna ||  |     5.456e9 |           -0.28% | > |             real/ben-raytrace ||  |    6.268e10 |           +2.87% | > |                     real/bspt ||  |     3.695e9 |           -0.12% | > |                real/cacheprof ||  |     3.822e9 |           +5.28% | > |                 real/compress ||  |     2.389e9 |           -0.41% | > |                real/compress2 ||  |     3.284e9 |           -4.00% | > |                   real/eff/CS ||  |     1.825e8 |           +0.07% | > |                  real/eff/CSD ||  |     1.185e9 |           -0.92% | > |                   real/eff/FS ||  |     9.959e8 |           +8.14% | > |                    real/eff/S ||  |     2.161e9 |           +3.14% | > |                   real/eff/VS ||  |     9.353e8 |           -4.17% | > |                  real/eff/VSD ||  |     2.326e7 |           +3.42% | > |                  real/eff/VSM ||  |     3.006e8 |          -15.15% | > |                      real/fem ||  |     3.274e9 |           -5.66% | > |                    real/fluid ||  |     3.224e9 |           -2.00% | > |                   real/fulsom ||  |     1.922e9 |           -1.85% | > |                   real/gamteb ||  |     5.555e9 |           -0.95% | > |                       real/gg ||  |     3.717e9 |           +6.49% | > |                     real/grep ||  |     3.266e9 |           -4.20% | > |                   real/hidden ||  |     5.666e9 |           -6.63% | > |                      real/hpg ||  |     3.082e9 |           +8.56% | > |                    real/infer ||  |     4.526e9 |           +4.02% | > |                     real/lift ||  |     3.450e9 |           -0.91% | > |                   real/linear ||  |     6.195e9 |           -3.28% | > |                 real/maillist ||  |     3.815e9 |           -3.44% | > |                  real/mkhprog ||  |     1.859e7 |           -4.29% | > |                   real/parser ||  |     3.315e9 |           +1.96% | > |                      real/pic ||  |     2.259e9 |           -2.02% | > |                   real/prolog ||  |     4.197e9 |           +0.39% | > |                  real/reptile ||  |     3.234e9 |           -1.87% | > |                      real/rsa ||  |     2.852e9 |           -1.52% | > |                      real/scs ||  |     2.870e9 |           -2.91% | > |                  real/smallpt ||  |     7.328e9 |           +0.78% | > |                   real/symalg ||  |     3.427e9 |           +0.10% | > |                  real/veritas ||  |     2.909e9 |           +0.50% | > |         shootout/binary-trees ||  |     5.018e9 |           -0.06% | > |       shootout/fannkuch-redux ||  |    1.014e10 |           -2.68% | > |                shootout/fasta ||  |     2.439e9 |           +1.45% | > |         shootout/k-nucleotide ||  |     3.488e9 |           +4.66% | > |               shootout/n-body ||  |     2.098e9 |           -0.03% | > |             shootout/pidigits ||  |     3.265e9 |           -0.18% | > |   shootout/reverse-complement ||  | 3311908.000 |           -6.15% | > |        shootout/spectral-norm ||  |     1.525e9 |           +0.62% | > |               smp/callback001 ||  |     8.318e8 |           +9.35% | > |               smp/callback002 ||  |     1.337e9 |           +5.34% | > |                      smp/chan ||  |     3.236e9 |           -0.99% | > |                     smp/sieve ||  |     7.368e8 |           -0.27% | > |                smp/threads001 ||  |     2.874e9 |           -0.77% | > |                smp/threads003 ||  |     1.841e9 |           -0.36% | > |                smp/threads006 ||  |     1.144e9 |           +2.09% | > |                smp/threads007 ||  |     3.534e9 |           +3.85% | > |                 spectral/ansi ||  |     1.973e9 |           -2.41% | > |                 spectral/atom ||  |     2.944e9 |           -0.80% | > |               spectral/awards ||  |     5.452e9 |          -11.68% | > |               spectral/banner ||  |     4.185e9 |           -0.68% | > |                spectral/boyer ||  |     4.195e9 |           -1.23% | > |               spectral/boyer2 ||  |     4.586e9 |           -1.21% | > |             spectral/calendar ||  |     3.726e9 |           -1.97% | > |             spectral/cichelli ||  |     4.325e9 |           -0.26% | > |              spectral/circsim ||  |     5.746e9 |           -0.23% | > |             spectral/clausify ||  |     3.735e9 |           +0.10% | > |          spectral/constraints ||  |     5.202e9 |           +2.10% | > |         spectral/cryptarithm1 ||  |     3.909e9 |           -4.03% | > |         spectral/cryptarithm2 ||  |     3.759e9 |           -1.27% | > |                  spectral/cse ||  |     4.564e9 |           -2.83% | > |               spectral/dom-lt ||  |     4.830e9 |           -0.05% | > |                spectral/eliza ||  |     4.631e9 |           -6.18% | > |          spectral/exact-reals ||  |     3.471e9 |           -0.08% | > |               spectral/expert ||  |     4.020e9 |           -1.27% | > |                 spectral/fft2 ||  |     4.706e9 |           -1.71% | > |             spectral/fibheaps ||  |     4.492e9 |           +0.55% | > |                 spectral/fish ||  |     4.004e9 |           +3.76% | > |                  spectral/gcd ||  |     3.413e9 |           -2.86% | > | spectral/hartel/comp_lab_zift ||  |     5.377e9 |           +4.10% | > |         spectral/hartel/event ||  |     5.456e9 |           -1.84% | > |           spectral/hartel/fft ||  |     1.732e9 |           +0.20% | > |        spectral/hartel/genfft ||  |     5.124e9 |           +2.82% | > |           spectral/hartel/ida ||  |     4.414e9 |           +2.00% | > |     spectral/hartel/listcompr ||  |     3.458e9 |           +3.84% | > |      spectral/hartel/listcopy ||  |     3.776e9 |           -4.30% | > |      spectral/hartel/nucleic2 ||  |     4.137e9 |           +4.49% | > |       spectral/hartel/parstof ||  |     4.609e9 |           -0.54% | > |         spectral/hartel/sched ||  |     4.245e9 |           -0.19% | > |         spectral/hartel/solid ||  |     3.587e9 |           +1.04% | > |     spectral/hartel/transform ||  |     3.793e9 |           +4.13% | > |     spectral/hartel/typecheck ||  |     4.627e9 |           -1.51% | > |          spectral/hartel/wang ||  |     4.369e9 |           -1.01% | > |     spectral/hartel/wave4main ||  |     4.844e9 |           -5.68% | > |              spectral/integer ||  |     3.150e9 |           -5.21% | > |              spectral/knights ||  |     4.198e9 |          +21.03% | > |               spectral/lambda ||  |     3.534e9 |           +1.90% | > |           spectral/last-piece ||  |     1.134e9 |           +0.65% | > |                 spectral/lcss ||  |     3.905e9 |           -0.64% | > |                 spectral/life ||  |     5.646e9 |           -6.52% | > |               spectral/mandel ||  |     3.529e9 |           -6.31% | > |              spectral/mandel2 ||  |     2.570e9 |           -0.24% | > |                 spectral/mate ||  |     5.761e9 |           +4.42% | > |              spectral/minimax ||  |     4.569e9 |           -1.24% | > |           spectral/multiplier ||  |     3.060e9 |           +6.04% | > |                 spectral/para ||  |     4.232e9 |           +1.90% | > |                spectral/power ||  |     3.808e9 |           -1.38% | > |               spectral/pretty ||  | 3403388.000 |          -22.39% | > |            spectral/primetest ||  |     3.203e9 |           -4.45% | > |               spectral/puzzle ||  |     4.362e9 |           -0.34% | > |              spectral/rewrite ||  |     3.840e9 |           +4.16% | > |                  spectral/scc ||  | 3133857.000 |           +1.57% | > |               spectral/simple ||  |     7.219e9 |           -1.59% | > |              spectral/sorting ||  |     4.285e9 |           -0.29% | > |               spectral/sphere ||  |     3.674e9 |           -3.88% | > |             spectral/treejoin ||  |     4.910e9 |           +0.19% | > +===============================++==+=============+==================+ > |                     geom mean ||  |      -0.80% |                  | > +-------------------------------++--+-------------+------------------+ > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From oleg.grenrus at iki.fi Wed Jul 7 15:11:41 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 18:11:41 +0300 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? Message-ID: For example - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration from primitive to base - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String behavior Why they are discussed "in private", I thought libraries@ list is where such changes should be discussed. - Oleg From carter.schonwald at gmail.com Wed Jul 7 15:42:26 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 7 Jul 2021 11:42:26 -0400 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: Message-ID: Agreed. This is a problem. I’ve tried to help make current clc folks aware of this privately a time or two this past year :( The only private part should be public coms on their discussion group to record voting on stuff that isn’t unanimous. Anything beyond that fails to align with healthy collaborative discourse norms More concerningly, only ~2-3 members of the current clc seem to be actively involved in public discussions on the library list or GitHub. And a deep misunderstanding that they need be maintainers of stuff that falls under the umbrella of core libraries now. Which is a fiction invented only on the past two years. Clc was formed to help guide decisions on base and be a suport for core libraries authors/maintainers. Not as an authority over those maintainers. There’s def problems with stuff and a lot of folks have privately expressed a lot of frustration about this over the past 12 months. On Wed, Jul 7, 2021 at 11:12 AM Oleg Grenrus wrote: > For example > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > from primitive to base > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > behavior > > Why they are discussed "in private", I thought libraries@ list is where > such changes should be discussed. > > - Oleg > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Jul 7 15:49:58 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 7 Jul 2021 17:49:58 +0200 (CEST) Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: Message-ID: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> On Wed, 7 Jul 2021, Oleg Grenrus wrote: > For example > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > from primitive to base > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > behavior > > Why they are discussed "in private", I thought libraries@ list is where > such changes should be discussed. I think so, too, and I missed them as well. From sandy at sandymaguire.me Wed Jul 7 16:41:19 2021 From: sandy at sandymaguire.me (Sandy Maguire) Date: Wed, 7 Jul 2021 09:41:19 -0700 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: At risk of being the messenger who gets shot.... As an outsider, it seems very reasonable to me to file a bug against the issue tracker for a project whose code I think should be changed. For better or worse, this is the way that 99% of software projects work. Expecting everyone in the community to know that they _shouldn't_ be filing bugs against the issue tracker is a losing battle. I'm more hooked in than most, and even I didn't know this. I can empathize with things not being done the way you'd like to be, but the claim that things happening on the GHC tracker are done "in private" is silly. The gitlab tracker is 10x more accessible, and the lack of community engagement on the mailing lists speaks volumes. And besides, nobody wants to be on a mailing list anyway. It's a terrible experience with weird branching and no persistence, and while there are archives, it's an extremely unpleasant thing to try to spelunk through. Best, Sandy On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Wed, 7 Jul 2021, Oleg Grenrus wrote: > > > For example > > > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > > from primitive to base > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > > behavior > > > > Why they are discussed "in private", I thought libraries@ list is where > > such changes should be discussed. > > I think so, too, and I missed them as well. > _______________________________________________ > 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 Wed Jul 7 17:10:02 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 20:10:02 +0300 Subject: RFC: Add HasCallStack constraint to partial Data.List functions. In-Reply-To: <3edcb1ed-0996-de7d-8624-04b5a6cb9f1d@iki.fi> References: <748a86ea-6f01-0970-1fb5-002295f7ae82@iki.fi> <3edcb1ed-0996-de7d-8624-04b5a6cb9f1d@iki.fi> Message-ID: After rereading https://wiki.haskell.org/Library_submissions page it actually says: > Following discussion, it's the responsibility of the core libraries committee to determine if the proposal should be accepted. Send an email to the core libraries committee requesting a decision, optionally including your own summary of the mailing list discussion. I submit this proposal to the core libraries committee. My summary is below: - there is (vague) Partial-constaint alternative proposal, which tries to discuss more elegant solution than to adding "operational" constraint to the functions. It's not concrete. - there are plenty of comments in support of HasCallStack too. So I ask the CLC to make a decision, whether HasCallStack is fine for now, or not. - Oleg On 5.7.2021 12.39, Oleg Grenrus wrote: > The discussion period for this proposal have ended. > > The most meritorious counter-argument/proposal is using Partial > constraint. [1] > I don't have counterarguments which would allow me simply discard that. > > I encourage Richard and Henrik to pursue that plan. > > So I have decided to drop this, HasCallStack, proposal. > > - Oleg > > P.S. I'd like to have formal process (like in [2]), and make a body > (CLC?) to > decide whether the alterantives have merits, so the process would have > chance to make progress. > > [1]: https://mail.haskell.org/pipermail/libraries/2021-June/031291.html > [2]: https://mail.haskell.org/pipermail/libraries/2021-July/031339.html > > On 30.5.2021 16.52, Oleg Grenrus wrote: >> I'm proposing to add HasCallStack constraint for partial functions >> in base package for functions in Data.List and Data.List.NonEmpty: >> >> - head, tail, init, last, ... >> - foldr1, foldl1, maximum, minimum, ... >> - (!!) >> >> --- >> >> The previous discussions started by Luo Chen can be found at >> https://gitlab.haskell.org/ghc/ghc/-/issues/17040 (from August 2019) >> >> and libraries list from June 2019 >> https://mail.haskell.org/pipermail/libraries/2019-June/029652.html >> >> --- >> >> My motivation comes from seeing GHCJS failing with >> "Prelude.!! negative index" exception and >> cabal-install with head of empty list. >> >> --- >> >> In #17040 issue Ben Gamari comments [1] >> >>> In general, adding HasCallStack constraints on things like simple >>> non-recursive functions like fromJust and head seems like a reasonable >>> trade-off; these functions will essentially always inline and >>> consequently the cost of the constraint will vanish. >> Such patch is now available at >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833 >> >> After accepting few changed test outputs, no further changes were needed. >> >> --- >> >> Ben continues: >> >>> Adding HasCallStack constraints on typeclass-overloaded methods isn't >>> as clear. After all, it's quite likely that these functions will be >>> reached by dynamic dispatch which will become more expensive with the >>> additional callstack argument. >> I agree. Foldable.foldr1 may not be partial, e.g. it isn't for NonEmpty. >> >> More correct approach would be to add Foldable1 [2] class to base, and >> in some distant future remove potentially partial members from Foldable. >> >> Therefore my patch _does not change_ Foldable. >> >>> nofib may not be a very good test for this patch as it doesn't contain >>> many uses of the affected functions >> Indeed. These functions are hardly ever in tight performance critical >> code, thus I'm skeptical about they affecting a code written by >> performance aware people. Re-implementing `head` in a loop where it >> causes performance regression is trivial. >> >> I have run `nofib` anyway. Results are at the end. >> >>> I think it would be a good idea to start with a minimal patch adding >>> constraints to the simple cases. We should then verify that the patch >>> doesn't affect the Core produced by typical use-cases (perhaps even >>> adding tests such that these don't regress). Once we know that the >>> simple cases are safe we can move on to the harder cases. >> Such patch is now available at >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833 >> >> --- >> >> Let me go through other comments in previous discussions, to have fuller >> overview. >> >> --- >> >> Some people are in favour, e.g. >> - Simon Jakobi, >> https://mail.haskell.org/pipermail/libraries/2019-June/029655.html >> - Hécate, https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_355561 >> >> --- >> >> Richard [3] thinks that e.g. a year prior addition of HasCallStack to >> fromJust >> [4] is not a right thing. >> >>> I don't have any particular insight to how to do call stacks better -- >>> and I am swayed by the argument that we need call stacks even in >>> production -- but I don't think HasCallStack is the way. That was >>> always meant as just a small hack! >> This patch is indeed more pragmatic than elegant, but takes us from >> takes us from spending potentially many hours finding the source of a >> crash to being pointed at the very line where it happens directly, which >> is invaluable for production systems.  I.e. let not (unknown) perfect be >> an enemy of good solution. >> >> --- >> >> In fromJust issue discussion [4] Ben comments >> >>> However, I should emphasize to that we don't want to simply scatter >>> HasCallStacks on every partial function. We should be thoughtful and >>> deliberate (and probably consult with the CLC) when making changes >>> like this. >> This email is indeed a request for CLC to comment. >> >> --- >> >> Edward Kmett comments was in favour [5] >> >>> I’m starting to warm to the idea of putting HasCallStack constraints >>> on the obviously partial combinators in base if we can demonstrate >>> that the performance impact isn't bad in practice, and even really, to >>> some extent if there is a somewhat middling impact on the performance >>> of code that leans on these hard to debug combinators, so long as the >>> performance of their more total siblings remains unaffected. The >>> impact on the perceived debuggability of Haskell seems _likely_ to >>> significantly outweigh the performance concerns. >> The results (to follow) shows that impact isn't bad. >> >>> Heck, off of the HEAD of cabal, which we’re encouraging folks to build >>> to play with the ghc 8.8.1 alpha, just today we ran into an issue >>> where the very build system we are using spat out an oh so informative >>> “Prelude.foldr1: Empty list” when using a pkgconfig-depends stanza >>> that didnt include any explicit bounds. >> --- >> >> David Feuer is worried about performance of recursive functions [6] >> >>> As I recall, the main things to watch out for, performance-wise, are >>> recursive definitions. When we throw an error from a library function, >>> we *typically* mean that the caller made a mistake. We don't want to >>> build up the call stacks we'd need to debug the library function >>> itself, unless we're actually doing so (in which case we can edit it >>> in, of course). >> In current base implementation all recursive functions (like foldr1, or >> !!) have internal workers, so the callstack is not building-up. >> >> Eric Seidel comments later [8] >> >>> What I remember finding back then was that there was a small overhead >>> for non-recursive functions like `head` but a substantial overhead for >>> recursive functions. >>>   I'd suggest extra care around recursive functions ((!!) comes to >>>   mind).  Perhaps rewrite them to use an inner recursive loop that does >>>   not extend the CallStack (this might produce nicer stacktraces >>>   anyway). >> That is how (!!) is currently written in base. It has an inner worker. >> (His benchmark link is not valid anymore, so I cannot tell what !! >> variant he benchmarked). >> >> --- >> >> Matthew Pickering comments [7] about -xc RTS flag. >> >>> I find this thread a bit concerning. In my opinion the current best >>> way to get call stacks on exceptions is with `-xc`. Adding runtime >>> overhead to every user program is not acceptable. >> -xc requires recompiling the program for profiling. >> >> He continues with >> >>> There is an argument that it would be good to disentangle `-xc` from >>> `prof` but you would still have to compile `base` in this way which >>> instruments these partial functions (as a user can not do it herself). >>> I'm not too sure on the details but I don't think -xc uses any >>> information from the profiling header so the fact it's connected with >>> -prof seems more like convenience than necessity. >> If that work is done, we can drop HasCallStack from partial functions, >> until then again let not perfect be the enemy of good. >> >> For example, me seeing GHCJS throwing on !!, of Edward cabal-install on >> foldr1 doesn't help. Rebuilding cabal-install with profiling is viable >> (but not for an average person who downloads it with ghcup), >> rebuilding GHCJS for profiling is a skill few people have. >> >> Already in his original proposal Luo Chen says: >> >>> When we run a long running program, such as a web service, it is not >>> easy to reproduce the issue, most of the time, you have no chance to >>> recompile or restart your program to debug, all you can rely on is the >>> printed logs, this makes -xc not as useful as HasCallStack. >> --- >> >> People are worried about performance. >> GHC itself uses some of the a affected functions. >> There are 30 foldr1, some head and tail calls, and also !! in `compiler/` >> >> The performance metrics in MR do not regress. >> GHC is not slowed down. >> >> I also run `nofib` using `--cachegrind -s Norm -j 16`, geometric means: >> >> - allocations: -0.12% >> - instructions: +0.05% >> - LLC cache misses: +0.58% >> - L1 cache misses: +0.03% >> >> And also using `--perf` (without `-j`): >> >> - perf instructions: +0.02% >> - perf cycles: -0.80% >> >> I don't know if this in bounds of "small changes to GHC". >> For me this looks acceptable. >> >> --- >> >> There is also off-thread blog post from 2018. >> https://neilmitchell.blogspot.com/2018/03/safe-library-with-better-stack-traces.html >> referencing e.g. >> https://hackage.haskell.org/package/extra-1.7.9/docs/Data-List-Extra.html#v:maximumOn >> and https://hackage.haskell.org/package/safe >> >> safe library has plenty of reverse dependencies: >> https://packdeps.haskellers.com/reverse/safe, and extra is used by shake. >> >> --- >> >> In summary: >> >> - fromJust has HasCallStack, head doesn't. Let us fix this. >> - Ben asked for patch so we can test performance, now such patch exists, >>   and it passes GHC CI. >> - GHC itself uses partial functions, its performance metrics don't >>   regress >> - -prof and +RTS -xc is an option, but it needs special build of an >>   executable. >> - This is ultimately for CLC to decide, so chessai, emilypi please tell >>   your opinion. >> >> Discussion period one month, until 2021-06-30 (end of June this year). >> >> Oleg >> >> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_231634 >> [2]: https://mail.haskell.org/pipermail/libraries/2019-November/030059.html >>      https://gitlab.haskell.org/ghc/ghc/-/issues/13573 >> [3]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_218035 >> [4]: https://gitlab.haskell.org/ghc/ghc/-/issues/15559 >> [5]: https://mail.haskell.org/pipermail/libraries/2019-June/029665.html >> [6]: https://mail.haskell.org/pipermail/libraries/2019-June/029666.html >> [7]: https://mail.haskell.org/pipermail/libraries/2019-June/029672.html >> [8]: https://mail.haskell.org/pipermail/libraries/2019-June/029667.html >> >> --- >> >> # bytes allocated >> >> +-------------------------------++--+-------------+------------------+ >> |                               ||  |     master/ | callstack/ (rel) | >> +===============================++==+=============+==================+ >> |          imaginary/bernouilli ||  |     2.823e9 |            0.00% | >> |        imaginary/digits-of-e1 ||  |     1.069e9 |            0.00% | >> |        imaginary/digits-of-e2 ||  |     2.152e9 |            0.00% | >> |              imaginary/exp3_8 ||  |     5.888e9 |            0.00% | >> |         imaginary/gen_regexps ||  |     9.104e8 |            0.00% | >> |           imaginary/integrate ||  |     3.768e9 |            0.00% | >> |               imaginary/kahan ||  |   49088.000 |            0.00% | >> |           imaginary/paraffins ||  |     3.829e9 |            0.00% | >> |              imaginary/primes ||  |     2.928e9 |            0.00% | >> |              imaginary/queens ||  |     6.709e8 |            0.00% | >> |                imaginary/rfib ||  |  139952.000 |            0.00% | >> |                 imaginary/tak ||  |   97344.000 |            0.00% | >> |        imaginary/wheel-sieve1 ||  |     1.344e8 |            0.00% | >> |        imaginary/wheel-sieve2 ||  |     2.430e9 |            0.00% | >> |                imaginary/x2n1 ||  |     2.561e8 |            0.00% | >> |         parallel/blackscholes ||  |     1.980e9 |            0.00% | >> |                parallel/coins ||  |     5.252e9 |            0.00% | >> |                 parallel/gray ||  |     2.010e9 |           +0.00% | >> |               parallel/mandel ||  |     8.524e9 |            0.00% | >> |              parallel/matmult ||  |     8.974e7 |            0.00% | >> |              parallel/minimax ||  |    2.212e10 |            0.00% | >> |                parallel/nbody ||  | 1498304.000 |            0.00% | >> |               parallel/parfib ||  |     3.651e8 |            0.00% | >> |              parallel/partree ||  |     3.290e9 |            0.00% | >> |                 parallel/prsa ||  |     2.097e9 |            0.00% | >> |               parallel/queens ||  |     6.846e8 |            0.00% | >> |                  parallel/ray ||  |    1.357e10 |            0.00% | >> |             parallel/sumeuler ||  | 1785016.000 |            0.00% | >> |            parallel/transclos ||  |     8.976e9 |            0.00% | >> |                     real/anna ||  |     2.022e9 |           +0.01% | >> |             real/ben-raytrace ||  |    3.418e10 |            0.00% | >> |                     real/bspt ||  |     3.747e9 |            0.00% | >> |                real/cacheprof ||  |     2.689e9 |            0.00% | >> |                 real/compress ||  |     2.807e9 |            0.00% | >> |                real/compress2 ||  |     3.436e9 |            0.00% | >> |                   real/eff/CS ||  |     1.601e8 |            0.00% | >> |                  real/eff/CSD ||  |     1.600e9 |            0.00% | >> |                   real/eff/FS ||  |     1.760e9 |            0.00% | >> |                    real/eff/S ||  |     2.401e8 |            0.00% | >> |                   real/eff/VS ||  |     4.831e8 |            0.00% | >> |                  real/eff/VSD ||  |   50736.000 |            0.00% | >> |                  real/eff/VSM ||  |     4.001e8 |            0.00% | >> |                      real/fem ||  |     4.947e9 |           -2.81% | >> |                    real/fluid ||  |     2.169e9 |           -0.00% | >> |                   real/fulsom ||  |     1.961e9 |            0.00% | >> |                   real/gamteb ||  |     4.447e9 |            0.00% | >> |                       real/gg ||  |     2.654e9 |            0.00% | >> |                     real/grep ||  |     4.623e9 |            0.00% | >> |                   real/hidden ||  |     5.100e9 |            0.00% | >> |                      real/hpg ||  |     3.160e9 |           -0.10% | >> |                    real/infer ||  |     1.731e9 |            0.00% | >> |                     real/lift ||  |     2.761e9 |            0.00% | >> |                   real/linear ||  |     5.412e9 |           -0.07% | >> |                 real/maillist ||  |     3.331e9 |            0.00% | >> |                  real/mkhprog ||  | 9748392.000 |            0.00% | >> |                   real/parser ||  |     2.666e9 |            0.00% | >> |                      real/pic ||  |     1.469e9 |            0.00% | >> |                   real/prolog ||  |     2.922e9 |           -0.02% | >> |                  real/reptile ||  |     5.121e9 |            0.00% | >> |                      real/rsa ||  |     8.414e8 |            0.00% | >> |                      real/scs ||  |     4.044e9 |            0.00% | >> |                  real/smallpt ||  |     2.874e9 |            0.00% | >> |                   real/symalg ||  |     3.195e8 |            0.00% | >> |                  real/veritas ||  |     4.172e9 |            0.00% | >> |         shootout/binary-trees ||  |     4.300e9 |            0.00% | >> |       shootout/fannkuch-redux ||  |   69144.000 |           -0.03% | >> |                shootout/fasta ||  |     1.718e9 |           +0.00% | >> |         shootout/k-nucleotide ||  |     7.081e7 |           +0.00% | >> |               shootout/n-body ||  |  130608.000 |            0.00% | >> |             shootout/pidigits ||  |    1.027e10 |            0.00% | >> |   shootout/reverse-complement ||  |   59768.000 |            0.00% | >> |        shootout/spectral-norm ||  |  178112.000 |            0.00% | >> |               smp/callback001 ||  |     1.114e9 |            0.00% | >> |               smp/callback002 ||  |     3.264e9 |            0.00% | >> |                      smp/chan ||  |     1.240e9 |            0.00% | >> |                     smp/sieve ||  |     1.410e9 |            0.00% | >> |                smp/threads001 ||  |    1.072e10 |            0.00% | >> |                smp/threads003 ||  |     3.051e8 |           -0.01% | >> |                smp/threads006 ||  |     2.242e8 |            0.00% | >> |                smp/threads007 ||  |     1.778e9 |           -0.00% | >> |                 spectral/ansi ||  |     6.713e9 |            0.00% | >> |                 spectral/atom ||  |     3.580e9 |            0.00% | >> |               spectral/awards ||  |     4.759e9 |            0.00% | >> |               spectral/banner ||  |     6.156e9 |            0.00% | >> |                spectral/boyer ||  |     4.665e9 |            0.00% | >> |               spectral/boyer2 ||  |     1.153e9 |            0.00% | >> |             spectral/calendar ||  |     7.102e9 |            0.00% | >> |             spectral/cichelli ||  |     1.969e9 |            0.00% | >> |              spectral/circsim ||  |     4.850e9 |            0.00% | >> |             spectral/clausify ||  |     2.095e9 |            0.00% | >> |          spectral/constraints ||  |     4.872e9 |            0.00% | >> |         spectral/cryptarithm1 ||  |     5.981e9 |            0.00% | >> |         spectral/cryptarithm2 ||  |     3.663e9 |            0.00% | >> |                  spectral/cse ||  |     3.802e9 |            0.00% | >> |               spectral/dom-lt ||  |     3.890e9 |            0.00% | >> |                spectral/eliza ||  |     4.102e9 |           +0.00% | >> |          spectral/exact-reals ||  |     9.584e8 |           -0.00% | >> |               spectral/expert ||  |     2.090e9 |            0.00% | >> |                 spectral/fft2 ||  |     1.431e9 |           -0.22% | >> |             spectral/fibheaps ||  |     4.737e9 |            0.00% | >> |                 spectral/fish ||  |     6.193e9 |            0.00% | >> |                  spectral/gcd ||  |     2.069e9 |            0.00% | >> | spectral/hartel/comp_lab_zift ||  |     4.740e9 |            0.00% | >> |         spectral/hartel/event ||  |     3.635e9 |          -12.13% | >> |           spectral/hartel/fft ||  |     1.611e9 |            0.00% | >> |        spectral/hartel/genfft ||  |     8.020e9 |            0.00% | >> |           spectral/hartel/ida ||  |     3.515e9 |            0.00% | >> |     spectral/hartel/listcompr ||  |     6.157e9 |            0.00% | >> |      spectral/hartel/listcopy ||  |     6.758e9 |            0.00% | >> |      spectral/hartel/nucleic2 ||  |     2.965e9 |            0.00% | >> |       spectral/hartel/parstof ||  |     1.368e9 |            0.00% | >> |         spectral/hartel/sched ||  |     3.675e9 |            0.00% | >> |         spectral/hartel/solid ||  |     3.509e9 |            0.00% | >> |     spectral/hartel/transform ||  |     3.959e9 |            0.00% | >> |     spectral/hartel/typecheck ||  |     2.570e9 |            0.00% | >> |          spectral/hartel/wang ||  |     4.735e9 |            0.00% | >> |     spectral/hartel/wave4main ||  |     1.147e9 |            0.00% | >> |              spectral/integer ||  |     3.260e9 |            0.00% | >> |              spectral/knights ||  |     1.094e9 |            0.00% | >> |               spectral/lambda ||  |     2.950e9 |            0.00% | >> |           spectral/last-piece ||  |     6.852e8 |            0.00% | >> |                 spectral/lcss ||  |     6.565e9 |            0.00% | >> |                 spectral/life ||  |     6.799e9 |            0.00% | >> |               spectral/mandel ||  |     1.972e9 |            0.00% | >> |              spectral/mandel2 ||  |     5.231e8 |            0.00% | >> |                 spectral/mate ||  |     4.598e9 |            0.00% | >> |              spectral/minimax ||  |     2.683e9 |            0.00% | >> |           spectral/multiplier ||  |     2.850e9 |            0.00% | >> |                 spectral/para ||  |     4.056e9 |            0.00% | >> |                spectral/power ||  |     1.428e9 |            0.00% | >> |               spectral/pretty ||  |  136880.000 |           -0.11% | >> |            spectral/primetest ||  |     8.455e8 |            0.00% | >> |               spectral/puzzle ||  |     1.809e9 |            0.00% | >> |              spectral/rewrite ||  |     1.694e9 |            0.00% | >> |                  spectral/scc ||  |   58280.000 |            0.00% | >> |               spectral/simple ||  |     2.316e9 |            0.00% | >> |              spectral/sorting ||  |     3.078e9 |            0.00% | >> |               spectral/sphere ||  |     2.298e9 |            0.00% | >> |             spectral/treejoin ||  |     2.796e9 |            0.00% | >> +===============================++==+=============+==================+ >> |                     geom mean ||  |      -0.12% |                  | >> +-------------------------------++--+-------------+------------------+ >> >> # instructions >> >> +-------------------------------++--+------------+------------------+ >> |                               ||  |    master/ | callstack/ (rel) | >> +===============================++==+============+==================+ >> |          imaginary/bernouilli ||  |    7.057e9 |           +0.00% | >> |        imaginary/digits-of-e1 ||  |    5.549e9 |           -0.00% | >> |        imaginary/digits-of-e2 ||  |    5.555e9 |           -0.01% | >> |              imaginary/exp3_8 ||  |    8.779e9 |           +0.03% | >> |         imaginary/gen_regexps ||  |    8.650e9 |           -0.00% | >> |           imaginary/integrate ||  |    6.276e9 |           +0.00% | >> |               imaginary/kahan ||  |    6.707e9 |           +0.00% | >> |           imaginary/paraffins ||  |    8.089e9 |           -0.00% | >> |              imaginary/primes ||  |    8.278e9 |           +0.01% | >> |              imaginary/queens ||  |   1.010e10 |           -0.00% | >> |                imaginary/rfib ||  |    5.299e9 |           +0.00% | >> |                 imaginary/tak ||  |    5.867e9 |           +0.00% | >> |        imaginary/wheel-sieve1 ||  |    6.615e9 |           +0.04% | >> |        imaginary/wheel-sieve2 ||  |    6.286e9 |           +0.02% | >> |                imaginary/x2n1 ||  |    7.452e9 |           +0.00% | >> |         parallel/blackscholes ||  |    8.022e9 |           +0.00% | >> |                parallel/coins ||  |   1.149e10 |           +0.00% | >> |                 parallel/gray ||  |    6.141e9 |           +0.14% | >> |               parallel/mandel ||  |   3.288e10 |           -0.01% | >> |              parallel/matmult ||  |   1.115e10 |           -0.00% | >> |              parallel/minimax ||  |   3.863e10 |           -0.08% | >> |                parallel/nbody ||  |    7.939e8 |           +0.00% | >> |               parallel/parfib ||  |   2.231e10 |           +0.00% | >> |              parallel/partree ||  |    7.347e9 |           +0.01% | >> |                 parallel/prsa ||  |   1.811e10 |           -0.00% | >> |               parallel/queens ||  |   1.037e10 |           +0.00% | >> |                  parallel/ray ||  |   1.299e10 |           +0.00% | >> |             parallel/sumeuler ||  |    3.483e9 |           +0.00% | >> |            parallel/transclos ||  |   1.982e10 |           +0.00% | >> |                     real/anna ||  |    5.343e9 |           +0.05% | >> |             real/ben-raytrace ||  |   1.215e11 |           +0.00% | >> |                     real/bspt ||  |    9.226e9 |           -0.00% | >> |                real/cacheprof ||  |    6.763e9 |           +0.02% | >> |                 real/compress ||  |    5.820e9 |           -0.00% | >> |                real/compress2 ||  |    4.569e9 |           +0.00% | >> |                   real/eff/CS ||  |    7.758e8 |           +0.00% | >> |                  real/eff/CSD ||  |    3.745e9 |           +0.00% | >> |                   real/eff/FS ||  |    2.799e9 |           +0.00% | >> |                    real/eff/S ||  |    4.334e9 |           +0.00% | >> |                   real/eff/VS ||  |    2.221e9 |           +0.01% | >> |                  real/eff/VSD ||  |    8.075e7 |           +0.00% | >> |                  real/eff/VSM ||  |    9.635e8 |           +0.00% | >> |                      real/fem ||  |    6.649e9 |           -0.64% | >> |                    real/fluid ||  |    3.904e9 |           -0.00% | >> |                   real/fulsom ||  |    2.490e9 |           +0.00% | >> |                   real/gamteb ||  |   1.013e10 |           +0.01% | >> |                       real/gg ||  |    7.253e9 |           +0.01% | >> |                     real/grep ||  |    7.546e9 |           +0.00% | >> |                   real/hidden ||  |    7.198e9 |           +1.64% | >> |                      real/hpg ||  |    4.966e9 |           +0.88% | >> |                    real/infer ||  |    8.318e9 |           +0.00% | >> |                     real/lift ||  |    4.430e9 |           -0.00% | >> |                   real/linear ||  |    8.436e9 |           +1.97% | >> |                 real/maillist ||  |    1.974e9 |           +0.05% | >> |                  real/mkhprog ||  |    2.249e7 |           +0.00% | >> |                   real/parser ||  |    5.178e9 |           -0.00% | >> |                      real/pic ||  |    3.268e9 |           -0.00% | >> |                   real/prolog ||  |    5.742e9 |           +0.01% | >> |                  real/reptile ||  |    6.046e9 |           +0.00% | >> |                      real/rsa ||  |    7.191e9 |           +0.00% | >> |                      real/scs ||  |    6.174e9 |           +0.00% | >> |                  real/smallpt ||  |   1.128e10 |           +0.00% | >> |                   real/symalg ||  |    8.230e9 |           +0.00% | >> |                  real/veritas ||  |    4.832e9 |           -0.01% | >> |         shootout/binary-trees ||  |   1.073e10 |           +0.01% | >> |       shootout/fannkuch-redux ||  |   1.909e10 |           -0.00% | >> |                shootout/fasta ||  |    4.189e9 |           +0.00% | >> |         shootout/k-nucleotide ||  |    4.219e9 |           +0.01% | >> |               shootout/n-body ||  |    3.721e9 |           +0.00% | >> |             shootout/pidigits ||  |    8.084e9 |           +0.00% | >> |   shootout/reverse-complement ||  | 781364.000 |           +0.51% | >> |        shootout/spectral-norm ||  |    4.252e9 |           +0.00% | >> |               smp/callback001 ||  |    1.573e9 |           +0.01% | >> |               smp/callback002 ||  |    2.621e9 |           +0.00% | >> |                      smp/chan ||  |    8.718e9 |           +2.56% | >> |                     smp/sieve ||  |    5.538e9 |           -0.87% | >> |                smp/threads001 ||  |    5.139e9 |           -0.00% | >> |                smp/threads003 ||  |    2.903e9 |           -0.05% | >> |                smp/threads006 ||  |    7.402e8 |           +0.01% | >> |                smp/threads007 ||  |    4.090e9 |           -0.00% | >> |                 spectral/ansi ||  |    5.961e9 |           -0.00% | >> |                 spectral/atom ||  |    5.861e9 |           +0.01% | >> |               spectral/awards ||  |    8.744e9 |           +0.00% | >> |               spectral/banner ||  |    8.824e9 |           +0.23% | >> |                spectral/boyer ||  |    7.657e9 |           -0.00% | >> |               spectral/boyer2 ||  |    8.881e9 |           -0.00% | >> |             spectral/calendar ||  |    7.546e9 |           -0.00% | >> |             spectral/cichelli ||  |    8.625e9 |           +0.01% | >> |              spectral/circsim ||  |    6.850e9 |           +0.00% | >> |             spectral/clausify ||  |    6.223e9 |           -0.00% | >> |          spectral/constraints ||  |    8.314e9 |           +0.14% | >> |         spectral/cryptarithm1 ||  |    7.787e9 |           -0.00% | >> |         spectral/cryptarithm2 ||  |    6.761e9 |           +0.00% | >> |                  spectral/cse ||  |    6.358e9 |           -0.00% | >> |               spectral/dom-lt ||  |    7.774e9 |           -0.00% | >> |                spectral/eliza ||  |    8.273e9 |           +0.00% | >> |          spectral/exact-reals ||  |    5.597e9 |           +0.01% | >> |               spectral/expert ||  |    5.087e9 |           +0.04% | >> |                 spectral/fft2 ||  |    8.831e9 |           +0.31% | >> |             spectral/fibheaps ||  |    8.011e9 |           -0.00% | >> |                 spectral/fish ||  |    7.314e9 |           -0.00% | >> |                  spectral/gcd ||  |    6.386e9 |           -0.00% | >> | spectral/hartel/comp_lab_zift ||  |    8.717e9 |           -0.00% | >> |         spectral/hartel/event ||  |    9.071e9 |           -2.06% | >> |           spectral/hartel/fft ||  |    3.239e9 |           +0.00% | >> |        spectral/hartel/genfft ||  |   1.020e10 |           +0.00% | >> |           spectral/hartel/ida ||  |    5.413e9 |           -0.30% | >> |     spectral/hartel/listcompr ||  |    6.142e9 |           +0.02% | >> |      spectral/hartel/listcopy ||  |    6.757e9 |           +0.02% | >> |      spectral/hartel/nucleic2 ||  |    4.402e9 |           +0.00% | >> |       spectral/hartel/parstof ||  |    5.555e9 |           -0.00% | >> |         spectral/hartel/sched ||  |    5.800e9 |           +0.00% | >> |         spectral/hartel/solid ||  |    5.845e9 |           +0.24% | >> |     spectral/hartel/transform ||  |    5.709e9 |           -0.00% | >> |     spectral/hartel/typecheck ||  |    5.841e9 |           +0.00% | >> |          spectral/hartel/wang ||  |    8.731e9 |           +0.12% | >> |     spectral/hartel/wave4main ||  |    6.024e9 |           -0.00% | >> |              spectral/integer ||  |    7.068e9 |           -0.00% | >> |              spectral/knights ||  |    8.294e9 |           -0.00% | >> |               spectral/lambda ||  |    8.081e9 |           +0.00% | >> |           spectral/last-piece ||  |    1.878e9 |           +0.00% | >> |                 spectral/lcss ||  |    8.761e9 |           -0.00% | >> |                 spectral/life ||  |    9.136e9 |           -0.00% | >> |               spectral/mandel ||  |    7.037e9 |           +0.00% | >> |              spectral/mandel2 ||  |    3.957e9 |           +0.00% | >> |                 spectral/mate ||  |    7.565e9 |           +0.01% | >> |              spectral/minimax ||  |    8.649e9 |           -0.00% | >> |           spectral/multiplier ||  |    6.096e9 |           +0.00% | >> |                 spectral/para ||  |    6.561e9 |           +0.00% | >> |                spectral/power ||  |    6.749e9 |           -0.00% | >> |               spectral/pretty ||  | 851224.000 |           +0.17% | >> |            spectral/primetest ||  |    7.391e9 |           -0.00% | >> |               spectral/puzzle ||  |    6.401e9 |           +0.00% | >> |              spectral/rewrite ||  |    5.553e9 |           +0.67% | >> |                  spectral/scc ||  | 774059.000 |           +0.49% | >> |               spectral/simple ||  |   1.214e10 |           +0.01% | >> |              spectral/sorting ||  |    9.074e9 |           -0.00% | >> |               spectral/sphere ||  |    5.371e9 |           -0.00% | >> |             spectral/treejoin ||  |    9.768e9 |           +0.00% | >> +===============================++==+============+==================+ >> |                     geom mean ||  |     +0.05% |                  | >> +-------------------------------++--+------------+------------------+ >> >> >> >> # LLC cache misses >> >> +-------------------------------++--+-------------+------------------+ >> |                               ||  |     master/ | callstack/ (rel) | >> +===============================++==+=============+==================+ >> |          imaginary/bernouilli ||  |    4964.000 |           +1.37% | >> |        imaginary/digits-of-e1 ||  |    4863.000 |           -0.35% | >> |        imaginary/digits-of-e2 ||  |    4958.000 |           +1.63% | >> |              imaginary/exp3_8 ||  |    4513.000 |           +0.42% | >> |         imaginary/gen_regexps ||  |    4535.000 |           +0.09% | >> |           imaginary/integrate ||  |    4733.000 |           +1.08% | >> |               imaginary/kahan ||  |    4447.000 |           -0.13% | >> |           imaginary/paraffins ||  |    4826.000 |           -0.08% | >> |              imaginary/primes ||  |    4876.000 |           +0.94% | >> |              imaginary/queens ||  |    4541.000 |           -0.07% | >> |                imaginary/rfib ||  |    4485.000 |           -0.13% | >> |                 imaginary/tak ||  |    4461.000 |           +0.25% | >> |        imaginary/wheel-sieve1 ||  |    4865.000 |           +1.29% | >> |        imaginary/wheel-sieve2 ||  |    4893.000 |           +1.25% | >> |                imaginary/x2n1 ||  |    4630.000 |           +0.22% | >> |         parallel/blackscholes ||  |   12862.000 |           +0.30% | >> |                parallel/coins ||  | 6455583.000 |           +0.00% | >> |                 parallel/gray ||  |    6372.000 |           +1.77% | >> |               parallel/mandel ||  |  852468.000 |           -0.02% | >> |              parallel/matmult ||  |    4615.000 |           -0.30% | >> |              parallel/minimax ||  |    4617.000 |           +0.84% | >> |                parallel/nbody ||  |    4455.000 |           -0.04% | >> |               parallel/parfib ||  |    4528.000 |           +0.22% | >> |              parallel/partree ||  |    4627.000 |           +0.43% | >> |                 parallel/prsa ||  |    4619.000 |           +0.54% | >> |               parallel/queens ||  |    4528.000 |           +1.37% | >> |                  parallel/ray ||  |    4626.000 |           +0.35% | >> |             parallel/sumeuler ||  |    4446.000 |           +0.13% | >> |            parallel/transclos ||  |    4741.000 |           -0.17% | >> |                     real/anna ||  |    6443.000 |           +5.34% | >> |             real/ben-raytrace ||  |    6819.000 |           -0.13% | >> |                     real/bspt ||  |    5195.000 |           -0.21% | >> |                real/cacheprof ||  |    6734.000 |           +1.62% | >> |                 real/compress ||  |    4914.000 |           +0.53% | >> |                real/compress2 ||  |    4783.000 |           -0.25% | >> |                   real/eff/CS ||  |    4439.000 |           +0.38% | >> |                  real/eff/CSD ||  |    4446.000 |            0.00% | >> |                   real/eff/FS ||  |    4451.000 |           -0.04% | >> |                    real/eff/S ||  | 5619842.000 |           -0.00% | >> |                   real/eff/VS ||  | 1254362.000 |           +0.00% | >> |                  real/eff/VSD ||  |    4403.000 |           -0.43% | >> |                  real/eff/VSM ||  |    4445.000 |           -0.11% | >> |                      real/fem ||  |    4967.000 |           +2.07% | >> |                    real/fluid ||  |    6117.000 |           +0.85% | >> |                   real/fulsom ||  |    5060.000 |           -0.10% | >> |                   real/gamteb ||  |    5615.000 |           +0.64% | >> |                       real/gg ||  |    5242.000 |           +0.88% | >> |                     real/grep ||  |    4866.000 |           +0.62% | >> |                   real/hidden ||  |    5576.000 |           +2.06% | >> |                      real/hpg ||  |    5614.000 |           +2.92% | >> |                    real/infer ||  |    4833.000 |           -0.14% | >> |                     real/lift ||  |    4809.000 |           +1.48% | >> |                   real/linear ||  |    5368.000 |           +4.53% | >> |                 real/maillist ||  |   12942.000 |           +0.32% | >> |                  real/mkhprog ||  |    4483.000 |           +0.20% | >> |                   real/parser ||  |    5309.000 |           +1.64% | >> |                      real/pic ||  |    4937.000 |           +0.81% | >> |                   real/prolog ||  |    4843.000 |           +1.03% | >> |                  real/reptile ||  |    5548.000 |           -0.43% | >> |                      real/rsa ||  |    4667.000 |           +0.26% | >> |                      real/scs ||  |    5667.000 |           +1.48% | >> |                  real/smallpt ||  |    5836.000 |           +1.29% | >> |                   real/symalg ||  |    5422.000 |           +0.30% | >> |                  real/veritas ||  |    6984.000 |           +2.61% | >> |         shootout/binary-trees ||  |    5079.000 |           +0.73% | >> |       shootout/fannkuch-redux ||  |    4478.000 |           -0.51% | >> |                shootout/fasta ||  |    4625.000 |           -0.13% | >> |         shootout/k-nucleotide ||  | 1161663.000 |           -2.58% | >> |               shootout/n-body ||  |    4512.000 |           +0.04% | >> |             shootout/pidigits ||  |    4651.000 |           -0.39% | >> |   shootout/reverse-complement ||  |    4416.000 |            0.00% | >> |        shootout/spectral-norm ||  |    4477.000 |           +0.25% | >> |               smp/callback001 ||  |  488453.000 |           -0.01% | >> |               smp/callback002 ||  |    4513.000 |           -0.11% | >> |                      smp/chan ||  |     1.110e7 |           +7.03% | >> |                     smp/sieve ||  |    4555.000 |           +0.72% | >> |                smp/threads001 ||  |    4481.000 |           +0.49% | >> |                smp/threads003 ||  |   83898.000 |           -1.63% | >> |                smp/threads006 ||  | 1804659.000 |           +0.49% | >> |                smp/threads007 ||  | 2427701.000 |           -0.24% | >> |                 spectral/ansi ||  |    4759.000 |           +0.27% | >> |                 spectral/atom ||  |    4691.000 |           +0.62% | >> |               spectral/awards ||  |    4717.000 |           +1.14% | >> |               spectral/banner ||  |    5056.000 |           +1.21% | >> |                spectral/boyer ||  |    5045.000 |           +0.06% | >> |               spectral/boyer2 ||  |    4832.000 |           -0.04% | >> |             spectral/calendar ||  |    4622.000 |           +0.74% | >> |             spectral/cichelli ||  |    4728.000 |           +1.67% | >> |              spectral/circsim ||  |   40269.000 |           -1.55% | >> |             spectral/clausify ||  |    4835.000 |           -0.17% | >> |          spectral/constraints ||  |    4871.000 |           +1.44% | >> |         spectral/cryptarithm1 ||  |    4562.000 |           +0.18% | >> |         spectral/cryptarithm2 ||  |    4600.000 |           +0.07% | >> |                  spectral/cse ||  |    4534.000 |           +0.33% | >> |               spectral/dom-lt ||  |    5179.000 |           +0.10% | >> |                spectral/eliza ||  |    4968.000 |           +0.34% | >> |          spectral/exact-reals ||  |    4840.000 |           +1.34% | >> |               spectral/expert ||  |    4770.000 |           +2.81% | >> |                 spectral/fft2 ||  |    5296.000 |           +1.91% | >> |             spectral/fibheaps ||  |    4858.000 |           +0.02% | >> |                 spectral/fish ||  |    4687.000 |           +0.04% | >> |                  spectral/gcd ||  |    4575.000 |           +0.22% | >> | spectral/hartel/comp_lab_zift ||  |    4960.000 |           +0.58% | >> |         spectral/hartel/event ||  |    4875.000 |           +0.96% | >> |           spectral/hartel/fft ||  |    5121.000 |           +0.70% | >> |        spectral/hartel/genfft ||  |    4875.000 |           +0.04% | >> |           spectral/hartel/ida ||  |    4877.000 |           +0.84% | >> |     spectral/hartel/listcompr ||  |    4651.000 |           +1.76% | >> |      spectral/hartel/listcopy ||  |    4649.000 |           +1.96% | >> |      spectral/hartel/nucleic2 ||  |    5998.000 |           +0.68% | >> |       spectral/hartel/parstof ||  |    5583.000 |           -0.05% | >> |         spectral/hartel/sched ||  |    4856.000 |           -0.23% | >> |         spectral/hartel/solid ||  |    5282.000 |           +1.21% | >> |     spectral/hartel/transform ||  |    4875.000 |           +1.56% | >> |     spectral/hartel/typecheck ||  |    4724.000 |           +0.95% | >> |          spectral/hartel/wang ||  |    4993.000 |           +2.38% | >> |     spectral/hartel/wave4main ||  |    4877.000 |           -0.04% | >> |              spectral/integer ||  |    4619.000 |           -0.13% | >> |              spectral/knights ||  |    4694.000 |           +0.58% | >> |               spectral/lambda ||  |    4984.000 |           +0.66% | >> |           spectral/last-piece ||  |    4869.000 |           -0.21% | >> |                 spectral/lcss ||  |    4876.000 |           +0.04% | >> |                 spectral/life ||  |    4884.000 |           +1.29% | >> |               spectral/mandel ||  |    4900.000 |           +0.16% | >> |              spectral/mandel2 ||  |    4479.000 |           -0.13% | >> |                 spectral/mate ||  |    5086.000 |           +1.83% | >> |              spectral/minimax ||  |    4605.000 |           -0.04% | >> |           spectral/multiplier ||  |    4672.000 |           +0.98% | >> |                 spectral/para ||  |    4935.000 |           +0.83% | >> |                spectral/power ||  |    4918.000 |           +0.18% | >> |               spectral/pretty ||  |    4432.000 |           +0.14% | >> |            spectral/primetest ||  |    5021.000 |           -0.04% | >> |               spectral/puzzle ||  |    4603.000 |           +0.04% | >> |              spectral/rewrite ||  |    4618.000 |           +0.97% | >> |                  spectral/scc ||  |    4415.000 |           +0.34% | >> |               spectral/simple ||  | 2413361.000 |           -1.18% | >> |              spectral/sorting ||  |    5357.000 |           -1.55% | >> |               spectral/sphere ||  |    5717.000 |           +0.84% | >> |             spectral/treejoin ||  |    5130.000 |           +0.02% | >> +===============================++==+=============+==================+ >> |                     geom mean ||  |      +0.58% |                  | >> +-------------------------------++--+-------------+------------------+ >> >> >> >> # L1 cache misses >> >> +-------------------------------++--+-------------+------------------+ >> |                               ||  |     master/ | callstack/ (rel) | >> +===============================++==+=============+==================+ >> |          imaginary/bernouilli ||  |     4.235e7 |           +0.13% | >> |        imaginary/digits-of-e1 ||  | 3708507.000 |           -0.06% | >> |        imaginary/digits-of-e2 ||  |     2.913e7 |           -0.16% | >> |              imaginary/exp3_8 ||  |     1.881e8 |           -0.07% | >> |         imaginary/gen_regexps ||  |     2.915e7 |           -0.05% | >> |           imaginary/integrate ||  | 1341520.000 |           -4.99% | >> |               imaginary/kahan ||  |    7577.000 |           +0.15% | >> |           imaginary/paraffins ||  |     5.994e7 |           -0.02% | >> |              imaginary/primes ||  |     1.165e8 |           -0.01% | >> |              imaginary/queens ||  |  315321.000 |           -0.94% | >> |                imaginary/rfib ||  |    7833.000 |           -0.46% | >> |                 imaginary/tak ||  |    7688.000 |           +0.03% | >> |        imaginary/wheel-sieve1 ||  | 7508229.000 |           +0.51% | >> |        imaginary/wheel-sieve2 ||  |     4.338e7 |           -0.02% | >> |                imaginary/x2n1 ||  |  129793.000 |           +0.50% | >> |         parallel/blackscholes ||  |     1.550e7 |           -0.16% | >> |                parallel/coins ||  |     3.952e7 |           +0.26% | >> |                 parallel/gray ||  |     1.736e7 |           +1.38% | >> |               parallel/mandel ||  |     1.356e7 |           +0.20% | >> |              parallel/matmult ||  |     5.267e8 |           -0.01% | >> |              parallel/minimax ||  |     1.140e8 |           -0.14% | >> |                parallel/nbody ||  |     1.248e7 |           -0.02% | >> |               parallel/parfib ||  |  252463.000 |           +6.49% | >> |              parallel/partree ||  |     5.642e7 |           +0.08% | >> |                 parallel/prsa ||  | 5700667.000 |           +0.27% | >> |               parallel/queens ||  | 3129546.000 |           +0.19% | >> |                  parallel/ray ||  |     1.260e7 |           +4.27% | >> |             parallel/sumeuler ||  |   35221.000 |           -0.07% | >> |            parallel/transclos ||  |     1.863e7 |           +0.17% | >> |                     real/anna ||  |     3.737e7 |           +0.10% | >> |             real/ben-raytrace ||  |     6.695e7 |           +0.59% | >> |                     real/bspt ||  |     1.492e8 |           +0.01% | >> |                real/cacheprof ||  |     5.661e7 |           -0.24% | >> |                 real/compress ||  |     3.247e7 |           -2.71% | >> |                real/compress2 ||  |     2.717e7 |           +0.13% | >> |                   real/eff/CS ||  |   54141.000 |           -0.28% | >> |                  real/eff/CSD ||  |  532877.000 |           -0.07% | >> |                   real/eff/FS ||  |  512883.000 |           +0.18% | >> |                    real/eff/S ||  |     1.412e7 |           -0.07% | >> |                   real/eff/VS ||  | 6730192.000 |           -0.42% | >> |                  real/eff/VSD ||  |    7449.000 |           -0.30% | >> |                  real/eff/VSM ||  |  121912.000 |           -0.22% | >> |                      real/fem ||  |     3.841e7 |           +6.86% | >> |                    real/fluid ||  |     1.579e7 |           +0.91% | >> |                   real/fulsom ||  |     1.036e7 |           +0.03% | >> |                   real/gamteb ||  |     3.473e7 |           -0.02% | >> |                       real/gg ||  |     7.439e7 |           +0.09% | >> |                     real/grep ||  |     7.940e7 |           +0.08% | >> |                   real/hidden ||  |     1.074e7 |           +0.20% | >> |                      real/hpg ||  |     1.757e7 |           +0.32% | >> |                    real/infer ||  |     2.006e8 |           -0.02% | >> |                     real/lift ||  |     2.741e7 |           +0.20% | >> |                   real/linear ||  |     8.899e7 |           +1.27% | >> |                 real/maillist ||  | 9646364.000 |           -0.06% | >> |                  real/mkhprog ||  |   11950.000 |           +3.72% | >> |                   real/parser ||  |     1.269e7 |           +0.92% | >> |                      real/pic ||  |     4.450e7 |           -0.24% | >> |                   real/prolog ||  |     2.973e7 |           -0.34% | >> |                  real/reptile ||  |     1.945e7 |           -0.07% | >> |                      real/rsa ||  | 1310283.000 |           -0.18% | >> |                      real/scs ||  |     1.916e7 |           +0.06% | >> |                  real/smallpt ||  | 7088127.000 |           +0.47% | >> |                   real/symalg ||  | 5981494.000 |           -0.11% | >> |                  real/veritas ||  |     1.860e7 |           -1.22% | >> |         shootout/binary-trees ||  |     3.661e7 |           +0.01% | >> |       shootout/fannkuch-redux ||  |    7741.000 |           -0.62% | >> |                shootout/fasta ||  |     5.215e7 |           +0.01% | >> |         shootout/k-nucleotide ||  |     1.247e7 |           +0.01% | >> |               shootout/n-body ||  |    8025.000 |           +0.04% | >> |             shootout/pidigits ||  |     2.316e8 |           +0.02% | >> |   shootout/reverse-complement ||  |    7627.000 |           -0.20% | >> |        shootout/spectral-norm ||  |   21764.000 |           +0.23% | >> |               smp/callback001 ||  | 5824201.000 |           +0.07% | >> |               smp/callback002 ||  | 8288204.000 |           -0.09% | >> |                      smp/chan ||  |     2.846e7 |           +2.62% | >> |                     smp/sieve ||  |     5.400e7 |           -1.10% | >> |                smp/threads001 ||  |     2.312e7 |           +0.45% | >> |                smp/threads003 ||  |     4.773e7 |           -0.22% | >> |                smp/threads006 ||  | 9331792.000 |           +0.02% | >> |                smp/threads007 ||  |     2.721e7 |           +0.36% | >> |                 spectral/ansi ||  |     6.940e7 |           -0.01% | >> |                 spectral/atom ||  |     1.248e8 |           +0.01% | >> |               spectral/awards ||  | 7810137.000 |           -1.82% | >> |               spectral/banner ||  |     3.727e7 |           +2.57% | >> |                spectral/boyer ||  |     2.284e7 |           -0.19% | >> |               spectral/boyer2 ||  |     3.926e7 |           -0.63% | >> |             spectral/calendar ||  | 7366268.000 |           -0.91% | >> |             spectral/cichelli ||  |     1.797e7 |           +0.02% | >> |              spectral/circsim ||  |     9.138e7 |           +0.07% | >> |             spectral/clausify ||  | 6134801.000 |           -0.11% | >> |          spectral/constraints ||  |     2.950e7 |           +0.38% | >> |         spectral/cryptarithm1 ||  | 3139494.000 |           +0.08% | >> |         spectral/cryptarithm2 ||  | 3481535.000 |           +0.35% | >> |                  spectral/cse ||  | 4798864.000 |           -7.01% | >> |               spectral/dom-lt ||  |     2.556e7 |           -0.11% | >> |                spectral/eliza ||  |     1.921e7 |           +1.14% | >> |          spectral/exact-reals ||  | 2391927.000 |           +1.24% | >> |               spectral/expert ||  |     2.311e7 |           -0.08% | >> |                 spectral/fft2 ||  |     1.917e8 |           +0.81% | >> |             spectral/fibheaps ||  |     5.236e7 |           -0.06% | >> |                 spectral/fish ||  | 8017906.000 |           +0.13% | >> |                  spectral/gcd ||  | 1652038.000 |           +0.07% | >> | spectral/hartel/comp_lab_zift ||  |     6.167e7 |           -0.11% | >> |         spectral/hartel/event ||  |     4.857e7 |           -2.47% | >> |           spectral/hartel/fft ||  |     3.723e7 |           -0.04% | >> |        spectral/hartel/genfft ||  |     2.201e7 |           +1.31% | >> |           spectral/hartel/ida ||  |     1.316e7 |           +0.16% | >> |     spectral/hartel/listcompr ||  | 9143834.000 |           +1.54% | >> |      spectral/hartel/listcopy ||  |     1.018e7 |           +2.27% | >> |      spectral/hartel/nucleic2 ||  |     1.035e7 |           -2.83% | >> |       spectral/hartel/parstof ||  |     2.290e7 |           -2.36% | >> |         spectral/hartel/sched ||  | 6090930.000 |           -0.15% | >> |         spectral/hartel/solid ||  |     3.408e7 |           +0.00% | >> |     spectral/hartel/transform ||  |     2.255e7 |           +0.25% | >> |     spectral/hartel/typecheck ||  |     1.447e7 |           -1.37% | >> |          spectral/hartel/wang ||  |     1.089e8 |           +0.19% | >> |     spectral/hartel/wave4main ||  |     8.229e7 |           +0.29% | >> |              spectral/integer ||  | 1101168.000 |           -0.06% | >> |              spectral/knights ||  |     3.424e7 |           +0.92% | >> |               spectral/lambda ||  |     6.667e7 |           +0.14% | >> |           spectral/last-piece ||  | 3620219.000 |           -0.43% | >> |                 spectral/lcss ||  |     7.252e7 |           -0.26% | >> |                 spectral/life ||  |     1.231e8 |           -0.11% | >> |               spectral/mandel ||  |  741678.000 |           +0.09% | >> |              spectral/mandel2 ||  |  311375.000 |           +0.79% | >> |                 spectral/mate ||  | 4858523.000 |           -1.23% | >> |              spectral/minimax ||  | 1172869.000 |           +0.51% | >> |           spectral/multiplier ||  |     1.060e8 |           +0.03% | >> |                 spectral/para ||  |     5.089e7 |           +0.15% | >> |                spectral/power ||  |     4.488e7 |           -0.00% | >> |               spectral/pretty ||  |    7649.000 |           +0.38% | >> |            spectral/primetest ||  |  500918.000 |           +1.32% | >> |               spectral/puzzle ||  | 3210919.000 |           -0.09% | >> |              spectral/rewrite ||  |  825290.000 |           -7.73% | >> |                  spectral/scc ||  |    7483.000 |           +0.16% | >> |               spectral/simple ||  |     8.786e7 |           +0.01% | >> |              spectral/sorting ||  |     1.261e8 |           -0.02% | >> |               spectral/sphere ||  | 4854033.000 |           +0.43% | >> |             spectral/treejoin ||  |     8.455e7 |           +0.03% | >> +===============================++==+=============+==================+ >> |                     geom mean ||  |      +0.03% |                  | >> +-------------------------------++--+-------------+------------------+ >> >> >> # perf instructions >> >> +-------------------------------++--+-------------+------------------+ >> |                               ||  |     master/ | callstack/ (rel) | >> +===============================++==+=============+==================+ >> |          imaginary/bernouilli ||  |     7.085e9 |           -0.22% | >> |        imaginary/digits-of-e1 ||  |     5.547e9 |           -0.03% | >> |        imaginary/digits-of-e2 ||  |     5.549e9 |           -0.06% | >> |              imaginary/exp3_8 ||  |     8.785e9 |           -0.06% | >> |         imaginary/gen_regexps ||  |     8.650e9 |           -0.04% | >> |           imaginary/integrate ||  |     6.260e9 |           +0.20% | >> |               imaginary/kahan ||  |     6.699e9 |           +0.16% | >> |           imaginary/paraffins ||  |     8.112e9 |           -0.24% | >> |              imaginary/primes ||  |     8.244e9 |           -0.24% | >> |              imaginary/queens ||  |    1.009e10 |           +0.04% | >> |                imaginary/rfib ||  |     5.298e9 |           +0.14% | >> |                 imaginary/tak ||  |     5.861e9 |           +0.10% | >> |        imaginary/wheel-sieve1 ||  |     6.662e9 |           -0.76% | >> |        imaginary/wheel-sieve2 ||  |     6.278e9 |           +0.38% | >> |                imaginary/x2n1 ||  |     7.453e9 |           -0.12% | >> |         parallel/blackscholes ||  |     8.096e9 |           -0.18% | >> |                parallel/coins ||  |    1.194e10 |           -0.03% | >> |                 parallel/gray ||  |     6.154e9 |           -0.07% | >> |               parallel/mandel ||  |    3.293e10 |           +0.12% | >> |              parallel/matmult ||  |    1.118e10 |           +0.06% | >> |              parallel/minimax ||  |    3.867e10 |           -0.11% | >> |                parallel/nbody ||  |     7.934e8 |           +0.05% | >> |               parallel/parfib ||  |    2.232e10 |           -0.01% | >> |              parallel/partree ||  |     7.358e9 |           +0.02% | >> |                 parallel/prsa ||  |    1.808e10 |           +0.14% | >> |               parallel/queens ||  |    1.037e10 |           -0.03% | >> |                  parallel/ray ||  |    1.301e10 |           +0.01% | >> |             parallel/sumeuler ||  |     3.487e9 |           -0.01% | >> |            parallel/transclos ||  |    1.983e10 |           -0.02% | >> |                     real/anna ||  |     5.334e9 |           +0.27% | >> |             real/ben-raytrace ||  |    1.216e11 |           -0.02% | >> |                     real/bspt ||  |     9.224e9 |           -0.05% | >> |                real/cacheprof ||  |     6.735e9 |           -0.46% | >> |                 real/compress ||  |     5.810e9 |           +0.07% | >> |                real/compress2 ||  |     4.580e9 |           -0.21% | >> |                   real/eff/CS ||  |     7.582e8 |           +1.19% | >> |                  real/eff/CSD ||  |     3.758e9 |           -0.56% | >> |                   real/eff/FS ||  |     2.792e9 |           +0.02% | >> |                    real/eff/S ||  |     4.760e9 |           -0.60% | >> |                   real/eff/VS ||  |     2.285e9 |           +0.20% | >> |                  real/eff/VSD ||  |     8.315e7 |           +0.02% | >> |                  real/eff/VSM ||  |     9.480e8 |           +1.48% | >> |                      real/fem ||  |     6.641e9 |           -0.53% | >> |                    real/fluid ||  |     3.914e9 |           +0.00% | >> |                   real/fulsom ||  |     2.497e9 |           -0.22% | >> |                   real/gamteb ||  |    1.013e10 |           -0.01% | >> |                       real/gg ||  |     7.243e9 |           +0.12% | >> |                     real/grep ||  |     7.563e9 |           -0.10% | >> |                   real/hidden ||  |     7.209e9 |           +1.57% | >> |                      real/hpg ||  |     4.982e9 |           +0.91% | >> |                    real/infer ||  |     8.312e9 |           +0.11% | >> |                     real/lift ||  |     4.441e9 |           -0.18% | >> |                   real/linear ||  |     8.438e9 |           +1.90% | >> |                 real/maillist ||  |     4.297e9 |           -0.94% | >> |                  real/mkhprog ||  |     2.874e7 |           -0.06% | >> |                   real/parser ||  |     5.177e9 |           +0.14% | >> |                      real/pic ||  |     3.265e9 |           +0.10% | >> |                   real/prolog ||  |     5.755e9 |           -0.18% | >> |                  real/reptile ||  |     6.050e9 |           +0.07% | >> |                      real/rsa ||  |     7.177e9 |           +0.03% | >> |                      real/scs ||  |     6.184e9 |           -0.23% | >> |                  real/smallpt ||  |    1.129e10 |           -0.16% | >> |                   real/symalg ||  |     8.247e9 |           -0.14% | >> |                  real/veritas ||  |     4.833e9 |           -0.01% | >> |         shootout/binary-trees ||  |    1.071e10 |           +0.12% | >> |       shootout/fannkuch-redux ||  |    1.912e10 |           +0.12% | >> |                shootout/fasta ||  |     4.273e9 |           -0.50% | >> |         shootout/k-nucleotide ||  |     4.227e9 |           -1.34% | >> |               shootout/n-body ||  |     3.725e9 |           -0.23% | >> |             shootout/pidigits ||  |     8.095e9 |           -0.04% | >> |   shootout/reverse-complement ||  | 3245583.000 |           -2.41% | >> |        shootout/spectral-norm ||  |     4.238e9 |           -0.15% | >> |               smp/callback001 ||  |     1.601e9 |           +0.55% | >> |               smp/callback002 ||  |     2.619e9 |           +0.19% | >> |                      smp/chan ||  |     7.817e9 |           -0.01% | >> |                     smp/sieve ||  |     2.361e9 |           +0.85% | >> |                smp/threads001 ||  |     5.145e9 |           +0.17% | >> |                smp/threads003 ||  |     2.922e9 |           -0.06% | >> |                smp/threads006 ||  |     1.081e9 |           +4.82% | >> |                smp/threads007 ||  |     4.328e9 |           +0.63% | >> |                 spectral/ansi ||  |     5.961e9 |           +0.21% | >> |                 spectral/atom ||  |     5.864e9 |           -0.10% | >> |               spectral/awards ||  |     8.749e9 |           -0.02% | >> |               spectral/banner ||  |     8.862e9 |           +0.12% | >> |                spectral/boyer ||  |     7.669e9 |           -0.09% | >> |               spectral/boyer2 ||  |     8.888e9 |           +0.04% | >> |             spectral/calendar ||  |     7.541e9 |           +0.13% | >> |             spectral/cichelli ||  |     8.675e9 |           -0.17% | >> |              spectral/circsim ||  |     6.901e9 |           +0.12% | >> |             spectral/clausify ||  |     6.227e9 |           -0.09% | >> |          spectral/constraints ||  |     8.308e9 |           +0.36% | >> |         spectral/cryptarithm1 ||  |     7.804e9 |           -0.23% | >> |         spectral/cryptarithm2 ||  |     6.757e9 |           +0.11% | >> |                  spectral/cse ||  |     6.357e9 |           +0.01% | >> |               spectral/dom-lt ||  |     7.774e9 |           +0.17% | >> |                spectral/eliza ||  |     8.279e9 |           -0.12% | >> |          spectral/exact-reals ||  |     5.599e9 |           -0.07% | >> |               spectral/expert ||  |     5.096e9 |           -0.09% | >> |                 spectral/fft2 ||  |     8.818e9 |           +0.48% | >> |             spectral/fibheaps ||  |     8.019e9 |           -0.12% | >> |                 spectral/fish ||  |     7.319e9 |           -0.03% | >> |                  spectral/gcd ||  |     6.381e9 |           +0.26% | >> | spectral/hartel/comp_lab_zift ||  |     8.747e9 |           -0.45% | >> |         spectral/hartel/event ||  |     9.153e9 |           -1.50% | >> |           spectral/hartel/fft ||  |     3.237e9 |           -0.02% | >> |        spectral/hartel/genfft ||  |    1.020e10 |           +0.14% | >> |           spectral/hartel/ida ||  |     5.420e9 |           -0.32% | >> |     spectral/hartel/listcompr ||  |     6.143e9 |           +0.12% | >> |      spectral/hartel/listcopy ||  |     6.759e9 |           +0.01% | >> |      spectral/hartel/nucleic2 ||  |     4.413e9 |           -0.67% | >> |       spectral/hartel/parstof ||  |     5.552e9 |           +0.04% | >> |         spectral/hartel/sched ||  |     5.807e9 |           -0.02% | >> |         spectral/hartel/solid ||  |     5.850e9 |           +0.22% | >> |     spectral/hartel/transform ||  |     5.713e9 |           -0.01% | >> |     spectral/hartel/typecheck ||  |     5.844e9 |           -0.04% | >> |          spectral/hartel/wang ||  |     8.727e9 |           +0.29% | >> |     spectral/hartel/wave4main ||  |     6.034e9 |           -0.20% | >> |              spectral/integer ||  |     7.048e9 |           +0.64% | >> |              spectral/knights ||  |     8.310e9 |           -0.08% | >> |               spectral/lambda ||  |     8.091e9 |           -0.12% | >> |           spectral/last-piece ||  |     1.877e9 |           +0.11% | >> |                 spectral/lcss ||  |     8.776e9 |           -0.10% | >> |                 spectral/life ||  |     9.143e9 |           -0.05% | >> |               spectral/mandel ||  |     7.015e9 |           +0.24% | >> |              spectral/mandel2 ||  |     3.957e9 |           +0.03% | >> |                 spectral/mate ||  |     7.573e9 |           +0.11% | >> |              spectral/minimax ||  |     8.645e9 |           +0.10% | >> |           spectral/multiplier ||  |     6.097e9 |           +0.06% | >> |                 spectral/para ||  |     6.562e9 |           +0.03% | >> |                spectral/power ||  |     6.758e9 |           -0.23% | >> |               spectral/pretty ||  | 3371581.000 |           -0.75% | >> |            spectral/primetest ||  |     7.409e9 |           -0.04% | >> |               spectral/puzzle ||  |     6.405e9 |           -0.19% | >> |              spectral/rewrite ||  |     5.558e9 |           +0.62% | >> |                  spectral/scc ||  | 3244220.000 |           -1.55% | >> |               spectral/simple ||  |    1.220e10 |           +0.25% | >> |              spectral/sorting ||  |     9.082e9 |           -0.05% | >> |               spectral/sphere ||  |     5.371e9 |           -0.18% | >> |             spectral/treejoin ||  |     9.881e9 |           -0.07% | >> +===============================++==+=============+==================+ >> |                     geom mean ||  |      +0.02% |                  | >> +-------------------------------++--+-------------+------------------+ >> >> >> >> # perf cycles >> >> +-------------------------------++--+-------------+------------------+ >> |                               ||  |     master/ | callstack/ (rel) | >> +===============================++==+=============+==================+ >> |          imaginary/bernouilli ||  |     3.726e9 |           +0.96% | >> |        imaginary/digits-of-e1 ||  |     2.561e9 |           +3.96% | >> |        imaginary/digits-of-e2 ||  |     2.828e9 |           -1.96% | >> |              imaginary/exp3_8 ||  |     3.231e9 |           +2.40% | >> |         imaginary/gen_regexps ||  |     4.250e9 |           +0.26% | >> |           imaginary/integrate ||  |     2.968e9 |           -9.55% | >> |               imaginary/kahan ||  |     3.062e9 |           -0.40% | >> |           imaginary/paraffins ||  |     3.083e9 |           -1.94% | >> |              imaginary/primes ||  |     2.593e9 |           +1.49% | >> |              imaginary/queens ||  |     4.713e9 |           -0.75% | >> |                imaginary/rfib ||  |     3.942e9 |           -0.09% | >> |                 imaginary/tak ||  |     4.385e9 |           -0.60% | >> |        imaginary/wheel-sieve1 ||  |     4.582e9 |          -43.27% | >> |        imaginary/wheel-sieve2 ||  |     2.563e9 |           -2.37% | >> |                imaginary/x2n1 ||  |     2.867e9 |           +0.10% | >> |         parallel/blackscholes ||  |     4.854e9 |           -1.40% | >> |                parallel/coins ||  |     4.809e9 |           -0.08% | >> |                 parallel/gray ||  |     3.600e9 |           +2.96% | >> |               parallel/mandel ||  |    1.481e10 |           -1.08% | >> |              parallel/matmult ||  |    1.570e10 |           -2.83% | >> |              parallel/minimax ||  |    2.420e10 |           +7.85% | >> |                parallel/nbody ||  |     4.377e8 |           +1.37% | >> |               parallel/parfib ||  |    1.752e10 |           +0.16% | >> |              parallel/partree ||  |     3.345e9 |           +2.19% | >> |                 parallel/prsa ||  |     7.052e9 |           +6.03% | >> |               parallel/queens ||  |     4.686e9 |           +0.06% | >> |                  parallel/ray ||  |     9.246e9 |           -2.73% | >> |             parallel/sumeuler ||  |     4.166e9 |           -1.20% | >> |            parallel/transclos ||  |    1.095e10 |           +1.05% | >> |                     real/anna ||  |     5.456e9 |           -0.28% | >> |             real/ben-raytrace ||  |    6.268e10 |           +2.87% | >> |                     real/bspt ||  |     3.695e9 |           -0.12% | >> |                real/cacheprof ||  |     3.822e9 |           +5.28% | >> |                 real/compress ||  |     2.389e9 |           -0.41% | >> |                real/compress2 ||  |     3.284e9 |           -4.00% | >> |                   real/eff/CS ||  |     1.825e8 |           +0.07% | >> |                  real/eff/CSD ||  |     1.185e9 |           -0.92% | >> |                   real/eff/FS ||  |     9.959e8 |           +8.14% | >> |                    real/eff/S ||  |     2.161e9 |           +3.14% | >> |                   real/eff/VS ||  |     9.353e8 |           -4.17% | >> |                  real/eff/VSD ||  |     2.326e7 |           +3.42% | >> |                  real/eff/VSM ||  |     3.006e8 |          -15.15% | >> |                      real/fem ||  |     3.274e9 |           -5.66% | >> |                    real/fluid ||  |     3.224e9 |           -2.00% | >> |                   real/fulsom ||  |     1.922e9 |           -1.85% | >> |                   real/gamteb ||  |     5.555e9 |           -0.95% | >> |                       real/gg ||  |     3.717e9 |           +6.49% | >> |                     real/grep ||  |     3.266e9 |           -4.20% | >> |                   real/hidden ||  |     5.666e9 |           -6.63% | >> |                      real/hpg ||  |     3.082e9 |           +8.56% | >> |                    real/infer ||  |     4.526e9 |           +4.02% | >> |                     real/lift ||  |     3.450e9 |           -0.91% | >> |                   real/linear ||  |     6.195e9 |           -3.28% | >> |                 real/maillist ||  |     3.815e9 |           -3.44% | >> |                  real/mkhprog ||  |     1.859e7 |           -4.29% | >> |                   real/parser ||  |     3.315e9 |           +1.96% | >> |                      real/pic ||  |     2.259e9 |           -2.02% | >> |                   real/prolog ||  |     4.197e9 |           +0.39% | >> |                  real/reptile ||  |     3.234e9 |           -1.87% | >> |                      real/rsa ||  |     2.852e9 |           -1.52% | >> |                      real/scs ||  |     2.870e9 |           -2.91% | >> |                  real/smallpt ||  |     7.328e9 |           +0.78% | >> |                   real/symalg ||  |     3.427e9 |           +0.10% | >> |                  real/veritas ||  |     2.909e9 |           +0.50% | >> |         shootout/binary-trees ||  |     5.018e9 |           -0.06% | >> |       shootout/fannkuch-redux ||  |    1.014e10 |           -2.68% | >> |                shootout/fasta ||  |     2.439e9 |           +1.45% | >> |         shootout/k-nucleotide ||  |     3.488e9 |           +4.66% | >> |               shootout/n-body ||  |     2.098e9 |           -0.03% | >> |             shootout/pidigits ||  |     3.265e9 |           -0.18% | >> |   shootout/reverse-complement ||  | 3311908.000 |           -6.15% | >> |        shootout/spectral-norm ||  |     1.525e9 |           +0.62% | >> |               smp/callback001 ||  |     8.318e8 |           +9.35% | >> |               smp/callback002 ||  |     1.337e9 |           +5.34% | >> |                      smp/chan ||  |     3.236e9 |           -0.99% | >> |                     smp/sieve ||  |     7.368e8 |           -0.27% | >> |                smp/threads001 ||  |     2.874e9 |           -0.77% | >> |                smp/threads003 ||  |     1.841e9 |           -0.36% | >> |                smp/threads006 ||  |     1.144e9 |           +2.09% | >> |                smp/threads007 ||  |     3.534e9 |           +3.85% | >> |                 spectral/ansi ||  |     1.973e9 |           -2.41% | >> |                 spectral/atom ||  |     2.944e9 |           -0.80% | >> |               spectral/awards ||  |     5.452e9 |          -11.68% | >> |               spectral/banner ||  |     4.185e9 |           -0.68% | >> |                spectral/boyer ||  |     4.195e9 |           -1.23% | >> |               spectral/boyer2 ||  |     4.586e9 |           -1.21% | >> |             spectral/calendar ||  |     3.726e9 |           -1.97% | >> |             spectral/cichelli ||  |     4.325e9 |           -0.26% | >> |              spectral/circsim ||  |     5.746e9 |           -0.23% | >> |             spectral/clausify ||  |     3.735e9 |           +0.10% | >> |          spectral/constraints ||  |     5.202e9 |           +2.10% | >> |         spectral/cryptarithm1 ||  |     3.909e9 |           -4.03% | >> |         spectral/cryptarithm2 ||  |     3.759e9 |           -1.27% | >> |                  spectral/cse ||  |     4.564e9 |           -2.83% | >> |               spectral/dom-lt ||  |     4.830e9 |           -0.05% | >> |                spectral/eliza ||  |     4.631e9 |           -6.18% | >> |          spectral/exact-reals ||  |     3.471e9 |           -0.08% | >> |               spectral/expert ||  |     4.020e9 |           -1.27% | >> |                 spectral/fft2 ||  |     4.706e9 |           -1.71% | >> |             spectral/fibheaps ||  |     4.492e9 |           +0.55% | >> |                 spectral/fish ||  |     4.004e9 |           +3.76% | >> |                  spectral/gcd ||  |     3.413e9 |           -2.86% | >> | spectral/hartel/comp_lab_zift ||  |     5.377e9 |           +4.10% | >> |         spectral/hartel/event ||  |     5.456e9 |           -1.84% | >> |           spectral/hartel/fft ||  |     1.732e9 |           +0.20% | >> |        spectral/hartel/genfft ||  |     5.124e9 |           +2.82% | >> |           spectral/hartel/ida ||  |     4.414e9 |           +2.00% | >> |     spectral/hartel/listcompr ||  |     3.458e9 |           +3.84% | >> |      spectral/hartel/listcopy ||  |     3.776e9 |           -4.30% | >> |      spectral/hartel/nucleic2 ||  |     4.137e9 |           +4.49% | >> |       spectral/hartel/parstof ||  |     4.609e9 |           -0.54% | >> |         spectral/hartel/sched ||  |     4.245e9 |           -0.19% | >> |         spectral/hartel/solid ||  |     3.587e9 |           +1.04% | >> |     spectral/hartel/transform ||  |     3.793e9 |           +4.13% | >> |     spectral/hartel/typecheck ||  |     4.627e9 |           -1.51% | >> |          spectral/hartel/wang ||  |     4.369e9 |           -1.01% | >> |     spectral/hartel/wave4main ||  |     4.844e9 |           -5.68% | >> |              spectral/integer ||  |     3.150e9 |           -5.21% | >> |              spectral/knights ||  |     4.198e9 |          +21.03% | >> |               spectral/lambda ||  |     3.534e9 |           +1.90% | >> |           spectral/last-piece ||  |     1.134e9 |           +0.65% | >> |                 spectral/lcss ||  |     3.905e9 |           -0.64% | >> |                 spectral/life ||  |     5.646e9 |           -6.52% | >> |               spectral/mandel ||  |     3.529e9 |           -6.31% | >> |              spectral/mandel2 ||  |     2.570e9 |           -0.24% | >> |                 spectral/mate ||  |     5.761e9 |           +4.42% | >> |              spectral/minimax ||  |     4.569e9 |           -1.24% | >> |           spectral/multiplier ||  |     3.060e9 |           +6.04% | >> |                 spectral/para ||  |     4.232e9 |           +1.90% | >> |                spectral/power ||  |     3.808e9 |           -1.38% | >> |               spectral/pretty ||  | 3403388.000 |          -22.39% | >> |            spectral/primetest ||  |     3.203e9 |           -4.45% | >> |               spectral/puzzle ||  |     4.362e9 |           -0.34% | >> |              spectral/rewrite ||  |     3.840e9 |           +4.16% | >> |                  spectral/scc ||  | 3133857.000 |           +1.57% | >> |               spectral/simple ||  |     7.219e9 |           -1.59% | >> |              spectral/sorting ||  |     4.285e9 |           -0.29% | >> |               spectral/sphere ||  |     3.674e9 |           -3.88% | >> |             spectral/treejoin ||  |     4.910e9 |           +0.19% | >> +===============================++==+=============+==================+ >> |                     geom mean ||  |      -0.80% |                  | >> +-------------------------------++--+-------------+------------------+ >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From taylor at fausak.me Wed Jul 7 17:29:15 2021 From: taylor at fausak.me (Taylor Fausak) Date: Wed, 7 Jul 2021 13:29:15 -0400 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: <65444DF0-FEF0-44FF-A389-C45B1342585C@fausak.me> As another outsider, I agree with everything that Sandy said. > On Jul 7, 2021, at 12:41 PM, Sandy Maguire wrote: > > At risk of being the messenger who gets shot.... > > As an outsider, it seems very reasonable to me to file a bug against the issue tracker for a project whose code I think should be changed. For better or worse, this is the way that 99% of software projects work. Expecting everyone in the community to know that they _shouldn't_ be filing bugs against the issue tracker is a losing battle. I'm more hooked in than most, and even I didn't know this. > > I can empathize with things not being done the way you'd like to be, but the claim that things happening on the GHC tracker are done "in private" is silly. The gitlab tracker is 10x more accessible, and the lack of community engagement on the mailing lists speaks volumes. > > And besides, nobody wants to be on a mailing list anyway. It's a terrible experience with weird branching and no persistence, and while there are archives, it's an extremely unpleasant thing to try to spelunk through. > > Best, > Sandy > > On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann > wrote: > > On Wed, 7 Jul 2021, Oleg Grenrus wrote: > > > For example > > > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > > from primitive to base > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > > behavior > > > > Why they are discussed "in private", I thought libraries@ list is where > > such changes should be discussed. > > I think so, too, and I missed them as well. > _______________________________________________ > 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 Wed Jul 7 17:32:43 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 20:32:43 +0300 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: Thanks for this reply. It made me reread https://wiki.haskell.org/Library_submissions page. In the Guide to proposers section it says: - All library proposals should start on the relevant issue tracker. - At this point, the library maintainer is responsible for taking next steps. - ... or decide that this is a controversial decision that must be discussed with the CLC. - If the CLC decides that the discussion must be discussed with the libraries@ mailing list, the original proposer may be asked to moderate the libraries@ mailing list discussion So do I understand right: it's up to the base-library maintainer to decide whether a change is controversial and must to be discussed with CLC, which in can elevate it to wider discussion or not. The page however lists Edward Kmett and Ryan Scott as base-maintainers, which I'm pretty sure is not right. Who are the base maintainers? I'm sorry for my misunderstanding, it seems you are right Sandy, the issues should be discussed in the issue trackers first, and only elevated to libraries@ list if CLC decides it needs to! That is much more reasonable then going to the libraries@ directly for every issue. - Oleg On 7.7.2021 19.41, Sandy Maguire wrote: > At risk of being the messenger who gets shot.... > > As an outsider, it seems very reasonable to me to file a bug against > the issue tracker for a project whose code I think should be changed. > For better or worse, this is the way that 99% of software projects > work. Expecting everyone in the community to know that they > _shouldn't_ be filing bugs against the issue tracker is a losing > battle. I'm more hooked in than most, and even I didn't know this. > > I can empathize with things not being done the way you'd like to be, > but the claim that things happening on the GHC tracker are done "in > private" is silly. The gitlab tracker is 10x more accessible, and the > lack of community engagement on the mailing lists speaks volumes. > > And besides, nobody wants to be on a mailing list anyway. It's a > terrible experience with weird branching and no persistence, and while > there are archives, it's an extremely unpleasant thing to try to > spelunk through. > > Best, > Sandy > > On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann > > > wrote: > > > On Wed, 7 Jul 2021, Oleg Grenrus wrote: > > > For example > > > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 > ByteArray > migration > > from primitive to base > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 > Changing Show > String > > behavior > > > > Why they are discussed "in private", I thought libraries@ list > is where > > such changes should be discussed. > > I think so, too, and I missed them as well. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jul 7 17:35:45 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 7 Jul 2021 13:35:45 -0400 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: Respectfully: some of us like mailing lists for complicated discussions :) The issue here is deviation from processs that support a wider range of participants with different accessibility needs and varying levels of volunteer time. More over, a mailing list is easier for curious parties to subscribe to and filter to a dedicated inbox. Have you ever tried doing robust mailbox filters for GitHub or gitlab? It’s pretty tricky without creating a firehose of all repo events unless you’re in a group that’s always tagged. Any ticket tagged core libraries on gitlab needs to have a corresponding email to this list for folks who aren’t administratively in that notification group. Or needs to link to a thread here motivating it. I’m on that notification list for gitlab because current clc folks wanted me to continue helping out, but that’s not a scalable open participation model. On Wed, Jul 7, 2021 at 12:41 PM Sandy Maguire wrote: > At risk of being the messenger who gets shot.... > > As an outsider, it seems very reasonable to me to file a bug against the > issue tracker for a project whose code I think should be changed. For > better or worse, this is the way that 99% of software projects work. > Expecting everyone in the community to know that they _shouldn't_ be filing > bugs against the issue tracker is a losing battle. I'm more hooked in than > most, and even I didn't know this. > > I can empathize with things not being done the way you'd like to be, but > the claim that things happening on the GHC tracker are done "in private" is > silly. The gitlab tracker is 10x more accessible, and the lack of community > engagement on the mailing lists speaks volumes. > > And besides, nobody wants to be on a mailing list anyway. It's a terrible > experience with weird branching and no persistence, and while there are > archives, it's an extremely unpleasant thing to try to spelunk through. > > Best, > Sandy > > On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Wed, 7 Jul 2021, Oleg Grenrus wrote: >> >> > For example >> > >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration >> > from primitive to base >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show >> String >> > behavior >> > >> > Why they are discussed "in private", I thought libraries@ list is where >> > such changes should be discussed. >> >> I think so, too, and I missed them as well. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jul 7 17:37:17 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 7 Jul 2021 13:37:17 -0400 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: It’s probably worth looking at the wiki edit history too. I’m pretty sure some edits were done to the policy in the past 18 months without community feedback or discussion. On Wed, Jul 7, 2021 at 1:33 PM Oleg Grenrus wrote: > Thanks for this reply. It made me reread > https://wiki.haskell.org/Library_submissions page. > In the Guide to proposers section it says: > > - All library proposals should start on the relevant issue tracker. > - At this point, the library maintainer is responsible for taking next > steps. > - ... or decide that this is a controversial decision that must be > discussed with the CLC. > > - If the CLC decides that the discussion must be discussed with the > libraries@ mailing list, the original proposer may be asked to moderate > the libraries@ mailing list discussion > > So do I understand right: it's up to the base-library maintainer to decide > whether a change is controversial and must to be discussed with CLC, which > in can elevate it to wider discussion or not. > > The page however lists Edward Kmett and Ryan Scott as base-maintainers, > which I'm pretty sure is not right. > Who are the base maintainers? > > I'm sorry for my misunderstanding, it seems you are right Sandy, the > issues should be discussed in the issue trackers first, and only elevated > to libraries@ list if CLC decides it needs to! > That is much more reasonable then going to the libraries@ directly for > every issue. > > > > - Oleg > > On 7.7.2021 19.41, Sandy Maguire wrote: > > At risk of being the messenger who gets shot.... > > As an outsider, it seems very reasonable to me to file a bug against the > issue tracker for a project whose code I think should be changed. For > better or worse, this is the way that 99% of software projects work. > Expecting everyone in the community to know that they _shouldn't_ be filing > bugs against the issue tracker is a losing battle. I'm more hooked in than > most, and even I didn't know this. > > I can empathize with things not being done the way you'd like to be, but > the claim that things happening on the GHC tracker are done "in private" is > silly. The gitlab tracker is 10x more accessible, and the lack of community > engagement on the mailing lists speaks volumes. > > And besides, nobody wants to be on a mailing list anyway. It's a terrible > experience with weird branching and no persistence, and while there are > archives, it's an extremely unpleasant thing to try to spelunk through. > > Best, > Sandy > > On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Wed, 7 Jul 2021, Oleg Grenrus wrote: >> >> > For example >> > >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration >> > from primitive to base >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show >> String >> > behavior >> > >> > Why they are discussed "in private", I thought libraries@ list is where >> > such changes should be discussed. >> >> I think so, too, and I missed them as well. >> _______________________________________________ >> 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 Wed Jul 7 17:41:14 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 20:41:14 +0300 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: As I understood from the https://wiki.haskell.org/Library_submissions page (to which GHC wiki links from https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#contributing-to-ghc), this job of elevating issue to the CLC is the job of a library maintainer. So I repeat my question: who are the current maintainer(s) of base library to make these calls. I'd like to know whom comments I can and cannot ignore when proposing changes, as everyone has an opinion on how base should be (myself including). - Oleg On 7.7.2021 20.35, Carter Schonwald wrote: > Respectfully: some of us like mailing lists for complicated > discussions :)  > > The issue here is deviation from processs that support a wider range > of participants with different accessibility needs and varying levels > of volunteer time.  > > More over, a mailing list is easier for curious parties to subscribe > to and filter to a dedicated inbox.  Have you ever tried doing robust > mailbox filters for GitHub or gitlab? It’s pretty tricky without > creating a firehose of all repo events unless you’re in a group that’s > always tagged.  > > Any ticket tagged core libraries on gitlab needs to have a > corresponding email to this list for folks who aren’t administratively > in that notification group. Or needs to link to a thread here > motivating it.  > > I’m on that notification list for gitlab because current clc folks > wanted me to continue helping out, but that’s not a scalable open > participation model.  > > On Wed, Jul 7, 2021 at 12:41 PM Sandy Maguire > wrote: > > At risk of being the messenger who gets shot.... > > As an outsider, it seems very reasonable to me to file a bug > against the issue tracker for a project whose code I think should > be changed. For better or worse, this is the way that 99% of > software projects work. Expecting everyone in the community to > know that they _shouldn't_ be filing bugs against the issue > tracker is a losing battle. I'm more hooked in than most, and even > I didn't know this. > > I can empathize with things not being done the way you'd like to > be, but the claim that things happening on the GHC tracker are > done "in private" is silly. The gitlab tracker is 10x more > accessible, and the lack of community engagement on the mailing > lists speaks volumes. > > And besides, nobody wants to be on a mailing list anyway. It's a > terrible experience with weird branching and no persistence, and > while there are archives, it's an extremely unpleasant thing to > try to spelunk through. > > Best, > Sandy > > On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann > > wrote: > > > On Wed, 7 Jul 2021, Oleg Grenrus wrote: > > > For example > > > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 > ByteArray > migration > > from primitive to base > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 > Changing > Show String > > behavior > > > > Why they are discussed "in private", I thought libraries@ > list is where > > such changes should be discussed. > > I think so, too, and I missed them as well. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Jul 7 17:41:54 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 20:41:54 +0300 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: There aren't. You are the last to edit that page: https://wiki.haskell.org/index.php?title=Library_submissions&action=history - Oleg On 7.7.2021 20.37, Carter Schonwald wrote: > It’s probably worth looking at the wiki edit history too.   > > I’m pretty sure some edits were done to the policy in the past 18 > months without community feedback or discussion.  > > On Wed, Jul 7, 2021 at 1:33 PM Oleg Grenrus > wrote: > > Thanks for this reply. It made me reread > https://wiki.haskell.org/Library_submissions > page. > In the Guide to proposers section it says: > > - All library proposals should start on the relevant issue tracker. > - At this point, the library maintainer is responsible for taking > next steps. > - ... or decide that this is a controversial decision that must be > discussed with the CLC. > > - If the CLC decides that the discussion must be discussed with > the libraries@ mailing list, the original proposer may be asked to > moderate the libraries@ mailing list discussion > > So do I understand right: it's up to the base-library maintainer > to decide whether a change is controversial and must to be > discussed with CLC, which in can elevate it to wider discussion or > not. > > The page however lists Edward Kmett and Ryan Scott as > base-maintainers, which I'm pretty sure is not right. > Who are the base maintainers? > > I'm sorry for my misunderstanding, it seems you are right Sandy, > the issues should be discussed in the issue trackers first, and > only elevated to libraries@ list if CLC decides it needs to! > That is much more reasonable then going to the libraries@ directly > for every issue. > > > > - Oleg > > On 7.7.2021 19.41, Sandy Maguire wrote: >> At risk of being the messenger who gets shot.... >> >> As an outsider, it seems very reasonable to me to file a bug >> against the issue tracker for a project whose code I think should >> be changed. For better or worse, this is the way that 99% of >> software projects work. Expecting everyone in the community to >> know that they _shouldn't_ be filing bugs against the issue >> tracker is a losing battle. I'm more hooked in than most, and >> even I didn't know this. >> >> I can empathize with things not being done the way you'd like to >> be, but the claim that things happening on the GHC tracker are >> done "in private" is silly. The gitlab tracker is 10x more >> accessible, and the lack of community engagement on the mailing >> lists speaks volumes. >> >> And besides, nobody wants to be on a mailing list anyway. It's a >> terrible experience with weird branching and no persistence, and >> while there are archives, it's an extremely unpleasant thing to >> try to spelunk through. >> >> Best, >> Sandy >> >> On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann >> > > wrote: >> >> >> On Wed, 7 Jul 2021, Oleg Grenrus wrote: >> >> > For example >> > >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 >> ByteArray >> migration >> > from primitive to base >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 >> Changing >> Show String >> > behavior >> > >> > Why they are discussed "in private", I thought libraries@ >> list is where >> > such changes should be discussed. >> >> I think so, too, and I missed them as well. >> _______________________________________________ >> 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 Jul 7 17:45:27 2021 From: chessai1996 at gmail.com (chessai) Date: Wed, 7 Jul 2021 12:45:27 -0500 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: I (chessai) am the current maintainer for base. On Wed, Jul 7, 2021, 12:41 Oleg Grenrus wrote: > As I understood from the https://wiki.haskell.org/Library_submissions > page (to which GHC wiki links from > https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#contributing-to-ghc), > this job of elevating issue to the CLC is the job of a library maintainer. > So I repeat my question: who are the current maintainer(s) of base library > to make these calls. > > I'd like to know whom comments I can and cannot ignore when proposing > changes, as everyone has an opinion on how base should be (myself > including). > > - Oleg > On 7.7.2021 20.35, Carter Schonwald wrote: > > Respectfully: some of us like mailing lists for complicated discussions :) > > The issue here is deviation from processs that support a wider range of > participants with different accessibility needs and varying levels of > volunteer time. > > More over, a mailing list is easier for curious parties to subscribe to > and filter to a dedicated inbox. Have you ever tried doing robust mailbox > filters for GitHub or gitlab? It’s pretty tricky without creating a > firehose of all repo events unless you’re in a group that’s always tagged. > > Any ticket tagged core libraries on gitlab needs to have a corresponding > email to this list for folks who aren’t administratively in that > notification group. Or needs to link to a thread here motivating it. > > I’m on that notification list for gitlab because current clc folks wanted > me to continue helping out, but that’s not a scalable open participation > model. > > On Wed, Jul 7, 2021 at 12:41 PM Sandy Maguire > wrote: > >> At risk of being the messenger who gets shot.... >> >> As an outsider, it seems very reasonable to me to file a bug against the >> issue tracker for a project whose code I think should be changed. For >> better or worse, this is the way that 99% of software projects work. >> Expecting everyone in the community to know that they _shouldn't_ be filing >> bugs against the issue tracker is a losing battle. I'm more hooked in than >> most, and even I didn't know this. >> >> I can empathize with things not being done the way you'd like to be, but >> the claim that things happening on the GHC tracker are done "in private" is >> silly. The gitlab tracker is 10x more accessible, and the lack of community >> engagement on the mailing lists speaks volumes. >> >> And besides, nobody wants to be on a mailing list anyway. It's a terrible >> experience with weird branching and no persistence, and while there are >> archives, it's an extremely unpleasant thing to try to spelunk through. >> >> Best, >> Sandy >> >> On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann < >> lemming at henning-thielemann.de> wrote: >> >>> >>> On Wed, 7 Jul 2021, Oleg Grenrus wrote: >>> >>> > For example >>> > >>> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray >>> migration >>> > from primitive to base >>> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show >>> String >>> > behavior >>> > >>> > Why they are discussed "in private", I thought libraries@ list is >>> where >>> > such changes should be discussed. >>> >>> I think so, too, and I missed them as well. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Wed Jul 7 17:52:24 2021 From: chessai1996 at gmail.com (chessai) Date: Wed, 7 Jul 2021 12:52:24 -0500 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: Message-ID: FWIW, I do believe that changing Show @String needs to be discussed on the list and I pinged the proposer to do so. The ByteArray change was in my/Andrew Martin's opinion that it was straightforward and sensible enough to not need the mailing list. As has been pointed out by Oleg, on the library submissions page, not all changes to any core library need to be discussed on the mailing list, as that would be a gross inefficiency and waste of time. Issue trackers are better, with escalation when necessary. On Wed, Jul 7, 2021, 10:12 Oleg Grenrus wrote: > For example > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > from primitive to base > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > behavior > > Why they are discussed "in private", I thought libraries@ list is where > such changes should be discussed. > > - Oleg > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Wed Jul 7 18:08:55 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 7 Jul 2021 21:08:55 +0300 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: <8e1c976a-a3ff-3a60-5b9e-316c6f6fb1eb@henning-thielemann.de> Message-ID: <8777ae42-e066-3c6b-8fe9-92df8ef28175@iki.fi> Could the library submissions page be updated to reflect that. I think that maintainers of random, template-haskell, primitive are not correct either. I'm not sure whether text and bytestring should be on the list as well. Also GHC Trac issue-tracker links are dead. - Oleg On 7.7.2021 20.45, chessai wrote: > I (chessai) am the current maintainer for base. > > On Wed, Jul 7, 2021, 12:41 Oleg Grenrus > wrote: > > As I understood from the > https://wiki.haskell.org/Library_submissions > page (to which GHC > wiki links from > https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#contributing-to-ghc > ), > this job of elevating issue to the CLC is the job of a library > maintainer. So I repeat my question: who are the current > maintainer(s) of base library to make these calls. > > I'd like to know whom comments I can and cannot ignore when > proposing changes, as everyone has an opinion on how base should > be (myself including). > > - Oleg > > On 7.7.2021 20.35, Carter Schonwald wrote: >> Respectfully: some of us like mailing lists for complicated >> discussions :)  >> >> The issue here is deviation from processs that support a wider >> range of participants with different accessibility needs and >> varying levels of volunteer time.  >> >> More over, a mailing list is easier for curious parties to >> subscribe to and filter to a dedicated inbox.  Have you ever >> tried doing robust mailbox filters for GitHub or gitlab? It’s >> pretty tricky without creating a firehose of all repo events >> unless you’re in a group that’s always tagged.  >> >> Any ticket tagged core libraries on gitlab needs to have a >> corresponding email to this list for folks who aren’t >> administratively in that notification group. Or needs to link to >> a thread here motivating it.  >> >> I’m on that notification list for gitlab because current clc >> folks wanted me to continue helping out, but that’s not a >> scalable open participation model.  >> >> On Wed, Jul 7, 2021 at 12:41 PM Sandy Maguire >> > wrote: >> >> At risk of being the messenger who gets shot.... >> >> As an outsider, it seems very reasonable to me to file a bug >> against the issue tracker for a project whose code I think >> should be changed. For better or worse, this is the way that >> 99% of software projects work. Expecting everyone in the >> community to know that they _shouldn't_ be filing bugs >> against the issue tracker is a losing battle. I'm more hooked >> in than most, and even I didn't know this. >> >> I can empathize with things not being done the way you'd like >> to be, but the claim that things happening on the GHC tracker >> are done "in private" is silly. The gitlab tracker is 10x >> more accessible, and the lack of community engagement on the >> mailing lists speaks volumes. >> >> And besides, nobody wants to be on a mailing list anyway. >> It's a terrible experience with weird branching and no >> persistence, and while there are archives, it's an extremely >> unpleasant thing to try to spelunk through. >> >> Best, >> Sandy >> >> On Wed, Jul 7, 2021 at 8:52 AM Henning Thielemann >> > > wrote: >> >> >> On Wed, 7 Jul 2021, Oleg Grenrus wrote: >> >> > For example >> > >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 >> >> ByteArray migration >> > from primitive to base >> > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 >> >> Changing Show String >> > behavior >> > >> > Why they are discussed "in private", I thought >> libraries@ list is where >> > such changes should be discussed. >> >> I think so, too, and I missed them as well. >> _______________________________________________ >> 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 andrew.lelechenko at gmail.com Wed Jul 7 18:23:40 2021 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Wed, 7 Jul 2021 19:23:40 +0100 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: References: Message-ID: <7A7FC0EB-50B9-4F40-BEB2-41433F8840A6@gmail.com> To put it blunt, libraries mail list has a reputation of a place, where things are never got done. Using it for any meaningful discussion is an obsolete practice and is actually less inclusive than relevant issue trackers. I suggest we use libraries mail list to announce (controversial) proposals, but rely on other, more suitable media to discuss them. Best regards, Andrew > Date: Wed, 7 Jul 2021 18:11:41 +0300 > From: Oleg Grenrus > > For example > > - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration > from primitive to base > - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String > behavior > > Why they are discussed "in private", I thought libraries@ list is where > such changes should be discussed. > > - Oleg From kenta at mit.edu Wed Jul 7 19:03:07 2021 From: kenta at mit.edu (Ken T Takusagawa) Date: Wed, 7 Jul 2021 15:03:07 -0400 (EDT) Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021, Carter Schonwald wrote: > This seems long overdue and aside from some redundant import warnings likely low breakage risk > Am I understanding correctly that this will cause any code that defines its own type named Natural to break? (I don't know how much code exists that does this.) And the proper workaround will be import Prelude hiding(Natural) ? I am not opposed to this proposal; I just want it to be clear what it will break. --ken From lemming at henning-thielemann.de Wed Jul 7 19:09:31 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 7 Jul 2021 21:09:31 +0200 (CEST) Subject: Export Natural type from prelude In-Reply-To: References: Message-ID: <1639f0f2-f7c8-931c-c3ec-c70fd589ff3@henning-thielemann.de> On Wed, 7 Jul 2021, Ken T Takusagawa wrote: > On Fri, 2 Jul 2021, Carter Schonwald wrote: > >> This seems long overdue and aside from some redundant import warnings likely low breakage risk > > Am I understanding correctly that this will cause any code > that defines its own type named Natural to break? right > And the proper workaround will be > import Prelude hiding(Natural) > ? this would work, but would cause warnings in older Prelude versions From hecate at glitchbra.in Wed Jul 7 20:42:17 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Wed, 7 Jul 2021 22:42:17 +0200 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: <7A7FC0EB-50B9-4F40-BEB2-41433F8840A6@gmail.com> References: <7A7FC0EB-50B9-4F40-BEB2-41433F8840A6@gmail.com> Message-ID: <6ac5317d-6ce1-8ecc-db03-a8325105108b@glitchbra.in> It is unfortunately true that whilst many excellent point of views have been given on subjects discussed on this mailing-list (and I have been lucky to benefit from them directly), it is also a terrible platform for the kind of feedback that most need when interacting with the CLC. I know it's complicated for the committee members to express an opinion publicly without the weight of their status. Regarding "controversial" proposals, I fear that the definition of the term according to the Wiki page is a bit too broad, and I think that we would benefit from a clarification regarding the process so that it depends less on bikeshedding as the main source of feedback for Core Libraries changes. I believe we have an invaluable source of knowledge in this mailing-list, but that it is not suited for some discussions that are being held here. The format of this mailing-list proves to be extremely painful and demotivating for people who wish to improve the status quo, and it is hard to make relevant comments without direct access to the patch so that conversations can revolve around the code. Le 07/07/2021 à 20:23, Andrew Lelechenko a écrit : > To put it blunt, libraries mail list has a reputation of a place, where things are never got done. Using it for any meaningful discussion is an obsolete practice and is actually less inclusive than relevant issue trackers. > > I suggest we use libraries mail list to announce (controversial) proposals, but rely on other, more suitable media to discuss them. > > Best regards, > Andrew > >> Date: Wed, 7 Jul 2021 18:11:41 +0300 >> From: Oleg Grenrus >> >> For example >> >> - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration >> from primitive to base >> - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String >> behavior >> >> Why they are discussed "in private", I thought libraries@ list is where >> such changes should be discussed. >> >> - Oleg > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From hecate at glitchbra.in Wed Jul 7 20:52:16 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Wed, 7 Jul 2021 22:52:16 +0200 Subject: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list? In-Reply-To: <6ac5317d-6ce1-8ecc-db03-a8325105108b@glitchbra.in> References: <7A7FC0EB-50B9-4F40-BEB2-41433F8840A6@gmail.com> <6ac5317d-6ce1-8ecc-db03-a8325105108b@glitchbra.in> Message-ID: <808b243a-e2f1-be88-3f0e-ce63974f8c36@glitchbra.in> I would like also to address the fact that the CLC's communication efforts suffer from a lack of attention that undermines its legitimacy when decisions like the ByteArray relocation are taken. I understand it is the CLC's prerogative to undertake such changes, but this is typically the kind of thing that warrants an announcement, and I bet people on this list would have wanted to learn about it through official channels rather than in the middle of a recriminations thread. Being a good communicator is indeed part of the required qualities of a core maintainer¹, it is a shame that this situation is not taken care of. Best regards, Hécate ¹ https://wiki.haskell.org/Core_Libraries_Committee#Maintainer_qualities Le 07/07/2021 à 22:42, Hécate a écrit : > It is unfortunately true that whilst many excellent point of views > have been given on subjects discussed on this mailing-list (and I have > been lucky to benefit from them directly), it is also a terrible > platform for the kind of feedback that most need when interacting with > the CLC. > I know it's complicated for the committee members to express an > opinion publicly without the weight of their status. > > Regarding "controversial" proposals, I fear that the definition of the > term according to the Wiki page is a bit too broad, and I think that > we would benefit from a clarification regarding the process so that it > depends less on bikeshedding as the main source of feedback for Core > Libraries changes. > > I believe we have an invaluable source of knowledge in this > mailing-list, but that it is not suited for some discussions that are > being held here. The format of this mailing-list proves to be > extremely painful and demotivating for people who wish to improve the > status quo, and it is hard to make relevant comments without direct > access to the patch so that conversations can revolve around the code. > > > Le 07/07/2021 à 20:23, Andrew Lelechenko a écrit : >> To put it blunt, libraries mail list has a reputation of a place, >> where things are never got done. Using it for any meaningful >> discussion is an obsolete practice and is actually less inclusive >> than relevant issue trackers. >> >> I suggest we use libraries mail list to announce (controversial) >> proposals, but rely on other, more suitable media to discuss them. >> >> Best regards, >> Andrew >> >>> Date: Wed, 7 Jul 2021 18:11:41 +0300 >>> From: Oleg Grenrus >>> >>> For example >>> >>> - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration >>> from primitive to base >>> - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show >>> String >>> behavior >>> >>> Why they are discussed "in private", I thought libraries@ list is where >>> such changes should be discussed. >>> >>> - Oleg >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From carter.schonwald at gmail.com Wed Jul 7 21:16:42 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 7 Jul 2021 17:16:42 -0400 Subject: Export Natural type from prelude In-Reply-To: <1639f0f2-f7c8-931c-c3ec-c70fd589ff3@henning-thielemann.de> References: <1639f0f2-f7c8-931c-c3ec-c70fd589ff3@henning-thielemann.de> Message-ID: Yeah. This is a good point. It’s worth doing a grep of definitions in hackage to see wha the blast radius is ofothwreiee working code. If there’s no breakage risk for old code, that’s a point in favor of inclusion of Natural in prelude rather than just being an extra import from base. If not, it’s a cost that must be weighed. On Wed, Jul 7, 2021 at 3:09 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Wed, 7 Jul 2021, Ken T Takusagawa wrote: > > > On Fri, 2 Jul 2021, Carter Schonwald wrote: > > > >> This seems long overdue and aside from some redundant import warnings > likely low breakage risk > > > > Am I understanding correctly that this will cause any code > > that defines its own type named Natural to break? > > right > > > And the proper workaround will be > > import Prelude hiding(Natural) > > ? > > this would work, but would cause warnings in older Prelude versions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jul 7 21:17:04 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 7 Jul 2021 17:17:04 -0400 Subject: Export Natural type from prelude In-Reply-To: References: <1639f0f2-f7c8-931c-c3ec-c70fd589ff3@henning-thielemann.de> Message-ID: I’ll have a look when I have time in a few days. On Wed, Jul 7, 2021 at 5:16 PM Carter Schonwald wrote: > Yeah. This is a good point. > > It’s worth doing a grep of definitions in hackage to see wha the blast > radius is ofothwreiee working code. If there’s no breakage risk for old > code, that’s a point in favor of inclusion of Natural in prelude rather > than just being an extra import from base. If not, it’s a cost that must > be weighed. > > On Wed, Jul 7, 2021 at 3:09 PM Henning Thielemann < > lemming at henning-thielemann.de> wrote: > >> >> On Wed, 7 Jul 2021, Ken T Takusagawa wrote: >> >> > On Fri, 2 Jul 2021, Carter Schonwald wrote: >> > >> >> This seems long overdue and aside from some redundant import warnings >> likely low breakage risk >> > >> > Am I understanding correctly that this will cause any code >> > that defines its own type named Natural to break? >> >> right >> >> > And the proper workaround will be >> > import Prelude hiding(Natural) >> > ? >> >> this would work, but would cause warnings in older Prelude versions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justksqsf at gmail.com Thu Jul 8 10:11:28 2021 From: justksqsf at gmail.com (Kai Ma) Date: Thu, 8 Jul 2021 18:11:28 +0800 Subject: [RFC] Support Unicode characters in instance Show String Message-ID: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> Hi all Two weeks ago, I proposed “Support Unicode characters in instance Show String” [0] in the GHC issue tracker, and chessai asked me to post it here for wider feedback. The proposal posted here is edited to reflect new ideas proposed and insights accumulated over the days: 1. (Proposal) Now the proposal itself is now modeled after Python. 2. (Alternative Options) Alternative 2 is the original proposal. 3. (Downsides) New. About breakage. 4. (Prior Art) New. 5. (Unresolved Problems) New. Included for discussion. Even though I wanted to summarize everything here, some insightful comments are perhaps not included or misunderstood. These original comments can be found at the original feature request. [0] https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Motivation ========== Unicode has been widely adopted and people around the world rely on Unicode to write in their native languages. Haskell, however, has been stuck in ASCII, and escape all non-ASCII characters in the String's instance of the Showclass, despite the fact that each element of a String is typically a Unicode code point, and putStrLn actually works as expected. Consider the following examples: ghci> print "Hello, 世界” "Hello, \19990\30028” ghci> print "Hello, мир” "Hello, \1084\1080\1088” ghci> print "Hello, κόσμος” "Hello, \954\972\963\956\959\962” ghci> "Hello, 世界" -- ghci calls `show`, so string literals are also escaped "Hello, \19990\30028” ghci> "😀" -- Not only human scripts, but also emojis! "\128512” This status quo is unsatisfactory for a number of reasons: 1. Even though it's small, it somehow creates an unwelcoming atmosphere for native speakers of languages whose scripts are not representable in ASCII. 2. This is an actual annoyance during debugging localized software, or strings with emojis. 3. Following 1, Haskell teachers are forced to use other languages instead of the students' mother tongues, or relying on I/O functions like putStrLn, creating a rather unnecessary burden. 4. Other string types, like Text [1], rely on this Show instance. Moreover, `read` already can handle Unicode strings today, so relaxing constraints on `show` doesn't affect `read . show == id`. Proposal ======== It's proposed here to change the Show instance of String, to achieve the following output: ghci> print "Hello, 世界” "Hello, 世界” ghci> print "Hello, мир” "Hello, мир” ghci> print "Hello, κόσμος” "Hello, κόσμος” ghci> "Hello, 世界” “Hello, 世界” ghci> "😀” “😀" More concretely, it means: 1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_ Unicode characters out of the range of ASCII. 2. Provide a function showEscaped or newtype Escaped = Escaped String to obtain the current escaping behavior, in case anyone wants the current behavior back. This proposal isn't about unescaping everything, but only readable Unicode characters. u_iswprint (GHC.Unicode.isPrint) seems to do the job, and indeed, there was a similar proposal before [2]. In summary, the behavior is similar to what Python `repr` does. Alternative Options =================== 1. Always use putStrLn. This is viable today but unsatisfactory as it requires stdout. In some cases, stdout is not accessible, e.g. Telegram or Discord bots. 2. Don't escape anything. `show` itself refrains from escaping most of the characters, and let ghci do the job instead. 3. Customize ghci instead. ghci intercepts output strings and check if they can be converted back to readable characters. This potentially allows for better compatibility with a variety of strangely behaving terminals, and finer-grained user control. Tom Ellis proposed `-interactive-print`-based solutions in the comment section. 4. A new language extension, e.g. ShowStringUnicode. Proposed by Julian Ospald. When enabled, readable Unicode characters are not escaped, and this is enabled by default by ghci. There are concerns about how this would affect cross-module behavior. Downsides ========= This is definitely a breaking change, but the breakage, to our current understanding, is limited. First, use of `show` in production code is discouraged. Even if someone really does that, the breakage only happens when one tries to send the "serialized" data over wire: Suppose Machine A `show`-ed a string and saved it into a UTF-8-encoded file, and sends it to Machine B, which expects another encoding. This would be surprising for those who are used to the old behavior. Second, though the breakage is not likely to be catastrophic for correct production code, test suites could be badly affected, as pointed out by Oleg Grenrus and vdukhovni in the comment section. Some test suites compare `show` results with expected results. vdukhovni further commented that Haskell escapes are not universally supported by non-Haskell tools, so the impact would be confined to Haskell. Prior Art ========= Python supports Unicode natively since 3. Python's approach is intuitive and capable. Its `repr`, which is equivalent to Haskell's `show`, automatically escapes unreadable characters, but leaves readable characters unescaped. The criteria of "readable" can be found in CPython's code [3]. If we were to realize this proposal, Python could be a source of inspiration. Unresolved Problems =================== There are some currently unresolved (not discussed enough) issues. + Locales. What if the specified locale does not support Unicode? Hécate Moonlight pointed out PEP-538 [4] could be a reference. + Unicode versions. Javran Cheng pointed out u_iswprint is generated from a Unicode table, which is manually updated. This raises a concern that the definition of "printable" characters could change from version to version. + Definition of "readable". Unicode already defined "printability". It's good, but it is not necessarily what we want here. - Should we support RTL? - Should we design a Haskell-specific definition of readability, to avoid Unciode version silently introducing breakage? (More?) Some issues here perhaps require better answers to: What is our expectation of Show? Where should it be used? Should we expect it to break on every Unicode update? [1] https://hackage.haskell.org/package/text-1.2.4.1/docs/src/Data.Text.Show.html#line-37 [2] https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html [3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Objects/unicodectype.c#L147 [4] https://www.python.org/dev/peps/pep-0538/ From hasufell at posteo.de Thu Jul 8 12:25:11 2021 From: hasufell at posteo.de (Julian Ospald) Date: Thu, 08 Jul 2021 12:25:11 +0000 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> Message-ID: Hi, I think most seemed to agree on the motivation, but would it be a lot of work to ping a few large opensource/industry projects about this and get a feel what they think or how much of an expected effort a migration would be? I'm afraid that we might take this too lightly and possibly cause a lot of engineering effort here. Our expectations how or how often people use "show" might or might not be accurate. I'm aware of e.g. the cardano wallet test suite (open source) and other cardano projects that are very large opon source codebases and may be affected. CCing duncan On July 8, 2021 10:11:28 AM UTC, Kai Ma wrote: >Hi all > >Two weeks ago, I proposed “Support Unicode characters in instance Show >String” [0] in the GHC issue tracker, and chessai asked me to post it >here for wider feedback. The proposal posted here is edited to reflect >new ideas proposed and insights accumulated over the days: > >1. (Proposal) Now the proposal itself is now modeled after Python. >2. (Alternative Options) Alternative 2 is the original proposal. >3. (Downsides) New. About breakage. >4. (Prior Art) New. >5. (Unresolved Problems) New. Included for discussion. > >Even though I wanted to summarize everything here, some insightful >comments are perhaps not included or misunderstood. These original >comments can be found at the original feature request. > >[0] https://gitlab.haskell.org/ghc/ghc/-/issues/20027 > > >Motivation >========== > >Unicode has been widely adopted and people around the world rely on >Unicode to write in their native languages. Haskell, however, has been >stuck in ASCII, and escape all non-ASCII characters in the String's >instance of the Showclass, despite the fact that each element of a >String is typically a Unicode code point, and putStrLn actually works >as >expected. Consider the following examples: > > ghci> print "Hello, 世界” > "Hello, \19990\30028” > > ghci> print "Hello, мир” > "Hello, \1084\1080\1088” > > ghci> print "Hello, κόσμος” > "Hello, \954\972\963\956\959\962” > >ghci> "Hello, 世界" -- ghci calls `show`, so string literals are >also escaped > "Hello, \19990\30028” > > ghci> "😀" -- Not only human scripts, but also emojis! > "\128512” > > >This status quo is unsatisfactory for a number of reasons: > >1. Even though it's small, it somehow creates an unwelcoming atmosphere > for native speakers of languages whose scripts are not representable > in ASCII. >2. This is an actual annoyance during debugging localized software, or > strings with emojis. >3. Following 1, Haskell teachers are forced to use other languages > instead of the students' mother tongues, or relying on I/O functions > like putStrLn, creating a rather unnecessary burden. >4. Other string types, like Text [1], rely on this Show instance. > >Moreover, `read` already can handle Unicode strings today, so relaxing >constraints on `show` doesn't affect `read . show == id`. > > >Proposal >======== > >It's proposed here to change the Show instance of String, to achieve >the following output: > > ghci> print "Hello, 世界” > "Hello, 世界” > > ghci> print "Hello, мир” > "Hello, мир” > > ghci> print "Hello, κόσμος” > "Hello, κόσμος” > > ghci> "Hello, 世界” > “Hello, 世界” > > ghci> "😀” > “😀" > >More concretely, it means: > >1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_ > Unicode characters out of the range of ASCII. >2. Provide a function showEscaped or newtype Escaped = Escaped String >to > obtain the current escaping behavior, in case anyone wants the > current behavior back. > >This proposal isn't about unescaping everything, but only readable >Unicode characters. u_iswprint (GHC.Unicode.isPrint) seems to do the >job, and indeed, there was a similar proposal before [2]. In summary, >the behavior is similar to what Python `repr` does. > > >Alternative Options >=================== > >1. Always use putStrLn. > > This is viable today but unsatisfactory as it requires stdout. In > some cases, stdout is not accessible, e.g. Telegram or Discord bots. > >2. Don't escape anything. > > `show` itself refrains from escaping most of the characters, and let > ghci do the job instead. > >3. Customize ghci instead. > > ghci intercepts output strings and check if they can be converted > back to readable characters. This potentially allows for better > compatibility with a variety of strangely behaving terminals, and > finer-grained user control. > > Tom Ellis proposed `-interactive-print`-based solutions in the > comment section. > >4. A new language extension, e.g. ShowStringUnicode. > > Proposed by Julian Ospald. When enabled, readable Unicode characters > are not escaped, and this is enabled by default by ghci. There are > concerns about how this would affect cross-module behavior. > > >Downsides >========= > >This is definitely a breaking change, but the breakage, to our current >understanding, is limited. > >First, use of `show` in production code is discouraged. Even if >someone >really does that, the breakage only happens when one tries to send the >"serialized" data over wire: > >Suppose Machine A `show`-ed a string and saved it into a UTF-8-encoded >file, and sends it to Machine B, which expects another encoding. This >would be surprising for those who are used to the old behavior. > >Second, though the breakage is not likely to be catastrophic for >correct >production code, test suites could be badly affected, as pointed out by >Oleg Grenrus and vdukhovni in the comment section. Some test suites >compare `show` results with expected results. vdukhovni further >commented that Haskell escapes are not universally supported by >non-Haskell tools, so the impact would be confined to Haskell. > > >Prior Art >========= > >Python supports Unicode natively since 3. Python's approach is >intuitive and capable. Its `repr`, which is equivalent to Haskell's >`show`, automatically escapes unreadable characters, but leaves >readable >characters unescaped. The criteria of "readable" can be found in >CPython's code [3]. If we were to realize this proposal, Python could >be a source of inspiration. > > >Unresolved Problems >=================== > >There are some currently unresolved (not discussed enough) issues. > >+ Locales. > > What if the specified locale does not support Unicode? Hécate > Moonlight pointed out PEP-538 [4] could be a reference. > >+ Unicode versions. > > Javran Cheng pointed out u_iswprint is generated from a Unicode table, > which is manually updated. This raises a concern that the definition > of "printable" characters could change from version to version. > >+ Definition of "readable". > > Unicode already defined "printability". It's good, but it is not > necessarily what we want here. > > - Should we support RTL? > - Should we design a Haskell-specific definition of readability, to > avoid Unciode version silently introducing breakage? > >(More?) > >Some issues here perhaps require better answers to: What is our >expectation of Show? Where should it be used? Should we expect it to >break on every Unicode update? > > >[1] >https://hackage.haskell.org/package/text-1.2.4.1/docs/src/Data.Text.Show.html#line-37 >[2] >https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html >[3] >https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Objects/unicodectype.c#L147 >[4] https://www.python.org/dev/peps/pep-0538/ > >_______________________________________________ >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 Thu Jul 8 15:53:38 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 8 Jul 2021 18:53:38 +0300 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> Message-ID: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Here is a simple patch, which I hope is close to what 1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_    Unicode characters out of the range of ASCII. of a proposed change will look like:     diff --git a/libraries/base/GHC/Show.hs b/libraries/base/GHC/Show.hs     index 84077e473b..24569168d4 100644     --- a/libraries/base/GHC/Show.hs     +++ b/libraries/base/GHC/Show.hs     @@ -364,7 +364,10 @@ showCommaSpace = showString ", "      -- > showLitChar '\n' s  =  "\\n" ++ s      --      showLitChar                :: Char -> ShowS     -showLitChar c s | c > '\DEL' =  showChar '\\' (protectEsc isDec (shows (ord c)) s)     +showLitChar c s | c > '\DEL' =     +    if isPrint c     +    then showChar c s     +    else  showChar '\\' (protectEsc isDec (shows (ord c)) s)      showLitChar '\DEL'         s =  showString "\\DEL" s      showLitChar '\\'           s =  showString "\\\\" s      showLitChar c s | c >= ' '   =  showChar c s     @@ -380,6 +383,13 @@ showLitChar c              s =  showString ('\\' : asciiTab!!ord c) s              -- I've done manual eta-expansion here, because otherwise it's              -- impossible to stop (asciiTab!!ord) getting floated out as an MFE          +-- Local definition of isPrint to avoid fighting with cycles for now.     +isPrint                 :: Char -> Bool     +isPrint    c = iswprint (ord c) /= 0     +     +foreign import ccall unsafe "u_iswprint"     +  iswprint :: Int -> Int     +      showLitString :: String -> ShowS      -- | Same as 'showLitChar', but for strings      -- It converts the string to a string using Haskell escape conventions I applied it to ghc-8.10 branch,     % _build/stage1/bin/ghc --interactive     GHCi, version 8.10.5: https://www.haskell.org/ghc/  :? for help     Prelude> "äiti"     "äiti"     Prelude> "мир"     "мир"     Prelude> print "мир"     "мир"     Prelude> "😀"     "😀" And then run test-suites of aeson, dhall and pandoc. Aeson test-suite passed. Dhall test-suites passed too, However pandoc testsuite failed: 78 out of 2819 tests failed (35.88s) An example failure is:     3587.md       #1:                                                            FAIL (0.01s)         --- test/command/3587.md         +++ pandoc -f latex -t native         +   1 [Para [Str "1 m",Space,Str "is",Space,Str "equal",Space,Str "to",Space,Str "1000 mm"]]         -   1 [Para [Str "1\160m",Space,Str "is",Space,Str "equal",Space,Str "to",Space,Str "1000\160mm"]] Str is a constructor of Inline type, and takes Text: data Inline = Str Text | ... As discussed on the GHC issue [1], Text and ByteString Show Instances piggyback on String instance. Bodigrim said that Text will eventually migrate to do the same as new Show String [2], so this issue will resurface. Please explain the compatibility story. How library writes should write their code (in test-suites) which rely on Show String or Show Text, such that they could support GHC base versions (and/or text) versions on the both sides of this breaking change. I agree with Julian that required migration engineering effort across (even just the open source) ecosystem is non-trivial. Having a good plan would hopefully make it easier to accept that cost. The fact it's a change which is not detectable at compile time makes me very anxious about this, even I don't disagree with motivation bits. I have very little idea if and where I depend on Show String behavior. It would also be interesting to see results of test-suites of all Stackage, but I leave it for someone else to do. - Oleg [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/20027 [2]: https://gitlab.haskell.org/ghc/ghc/-/issues/20027#note_363519 On 8.7.2021 15.25, Julian Ospald wrote: > Hi, > > I think most seemed to agree on the motivation, but would it be a lot > of work to ping a few large opensource/industry projects about this > and get a feel what they think or how much of an expected effort a > migration would be? I'm afraid that we might take this too lightly and > possibly cause a lot of engineering effort here. Our expectations how > or how often people use "show" might or might not be accurate. > > I'm aware of e.g. the cardano wallet test suite (open source) and > other cardano projects that are very large opon source codebases and > may be affected. > > CCing duncan > > On July 8, 2021 10:11:28 AM UTC, Kai Ma wrote: > > Hi all > > Two weeks ago, I proposed “Support Unicode characters in instance Show > String” [0] in the GHC issue tracker, and chessai asked me to post it > here for wider feedback. The proposal posted here is edited to reflect > new ideas proposed and insights accumulated over the days: > > 1. (Proposal) Now the proposal itself is now modeled after Python. > 2. (Alternative Options) Alternative 2 is the original proposal. > 3. (Downsides) New. About breakage. > 4. (Prior Art) New. > 5. (Unresolved Problems) New. Included for discussion. > > Even though I wanted to summarize everything here, some insightful > comments are perhaps not included or misunderstood. These original > comments can be found at the original feature request. > > [0] https://gitlab.haskell.org/ghc/ghc/-/issues/20027 > > > Motivation > ------------------------------------------------------------------------ > Unicode has been widely adopted and people around the world rely on > Unicode to write in their native languages. Haskell, however, has been > stuck in ASCII, and escape all non-ASCII characters in the String's > instance of the Showclass, despite the fact that each element of a > String is typically a Unicode code point, and putStrLn actually works as > expected. Consider the following examples: > > ghci> print "Hello, 世界” > "Hello, \19990\30028” > > ghci> print "Hello, мир” > "Hello, \1084\1080\1088” > > ghci> print "Hello, κόσμος” > "Hello, \954\972\963\956\959\962” > > ghci> "Hello, 世界" -- ghci calls `show`, so string literals are also escaped > "Hello, \19990\30028” > > ghci> "😀" -- Not only human scripts, but also emojis! > "\128512” > > > This status quo is unsatisfactory for a number of reasons: > > 1. Even though it's small, it somehow creates an unwelcoming atmosphere > for native speakers of languages whose scripts are not representable > in ASCII. > 2. This is an actual annoyance during debugging localized software, or > strings with emojis. > 3. Following 1, Haskell teachers are forced to use other languages > instead of the students' mother tongues, or relying on I/O functions > like putStrLn, creating a rather unnecessary burden. > 4. Other string types, like Text [1], rely on this Show instance. > > Moreover, `read` already can handle Unicode strings today, so relaxing > constraints on `show` doesn't affect `read . show == id`. > > > Proposal > ------------------------------------------------------------------------ > It's proposed here to change the Show instance of String, to achieve the following output: > > ghci> print "Hello, 世界” > "Hello, 世界” > > ghci> print "Hello, мир” > "Hello, мир” > > ghci> print "Hello, κόσμος” > "Hello, κόσμος” > > ghci> "Hello, 世界” > “Hello, 世界” > > ghci> "😀” > “😀" > > More concretely, it means: > > 1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_ > Unicode characters out of the range of ASCII. > 2. Provide a function showEscaped or newtype Escaped = Escaped String to > obtain the current escaping behavior, in case anyone wants the > current behavior back. > > This proposal isn't about unescaping everything, but only readable > Unicode characters. u_iswprint (GHC.Unicode.isPrint) seems to do the > job, and indeed, there was a similar proposal before [2]. In summary, > the behavior is similar to what Python `repr` does. > > > Alternative Options > ------------------------------------------------------------------------ > 1. Always use putStrLn. > > This is viable today but unsatisfactory as it requires stdout. In > some cases, stdout is not accessible, e.g. Telegram or Discord bots. > > 2. Don't escape anything. > > `show` itself refrains from escaping most of the characters, and let > ghci do the job instead. > > 3. Customize ghci instead. > > ghci intercepts output strings and check if they can be converted > back to readable characters. This potentially allows for better > compatibility with a variety of strangely behaving terminals, and > finer-grained user control. > > Tom Ellis proposed `-interactive-print`-based solutions in the > comment section. > > 4. A new language extension, e.g. ShowStringUnicode. > > Proposed by Julian Ospald. When enabled, readable Unicode characters > are not escaped, and this is enabled by default by ghci. There are > concerns about how this would affect cross-module behavior. > > > Downsides > ------------------------------------------------------------------------ > This is definitely a breaking change, but the breakage, to our current > understanding, is limited. > > First, use of `show` in production code is discouraged. Even if someone > really does that, the breakage only happens when one tries to send the > "serialized" data over wire: > > Suppose Machine A `show`-ed a string and saved it into a UTF-8-encoded > file, and sends it to Machine B, which expects another encoding. This > would be surprising for those who are used to the old behavior. > > Second, though the breakage is not likely to be catastrophic for correct > production code, test suites could be badly affected, as pointed out by > Oleg Grenrus and vdukhovni in the comment section. Some test suites > compare `show` results with expected results. vdukhovni further > commented that Haskell escapes are not universally supported by > non-Haskell tools, so the impact would be confined to Haskell. > > > Prior Art > ------------------------------------------------------------------------ > Python supports Unicode natively since 3. Python's approach is > intuitive and capable. Its `repr`, which is equivalent to Haskell's > `show`, automatically escapes unreadable characters, but leaves readable > characters unescaped. The criteria of "readable" can be found in > CPython's code [3]. If we were to realize this proposal, Python could > be a source of inspiration. > > > Unresolved Problems > ------------------------------------------------------------------------ > There are some currently unresolved (not discussed enough) issues. > > + Locales. > > What if the specified locale does not support Unicode? Hécate > Moonlight pointed out PEP-538 [4] could be a reference. > > + Unicode versions. > > Javran Cheng pointed out u_iswprint is generated from a Unicode table, > which is manually updated. This raises a concern that the definition > of "printable" characters could change from version to version. > > + Definition of "readable". > > Unicode already defined "printability". It's good, but it is not > necessarily what we want here. > > - Should we support RTL? > - Should we design a Haskell-specific definition of readability, to > avoid Unciode version silently introducing breakage? > > (More?) > > Some issues here perhaps require better answers to: What is our > expectation of Show? Where should it be used? Should we expect it to > break on every Unicode update? > > > [1] https://hackage.haskell.org/package/text-1.2.4.1/docs/src/Data.Text.Show.html#line-37 > [2] https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html > [3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Objects/unicodectype.c#L147 > [4] https://www.python.org/dev/peps/pep-0538/ > ------------------------------------------------------------------------ > 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 spam at scientician.net Thu Jul 8 16:38:06 2021 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 8 Jul 2021 18:38:06 +0200 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: On 08/07/2021 17.53, Oleg Grenrus wrote: [--snip--] > > 78 out of 2819 tests failed (35.88s) > The use of Show in 'golden' test suites is interesting because Show doesn't really guarantee any real form of stability in its output. I guess Hyrum's Law applies here too. Anyway... just an idle observation. Obviously, breaking loads of test suites is going to be hard to swallow. Regards, From oleg.grenrus at iki.fi Thu Jul 8 17:17:06 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 8 Jul 2021 20:17:06 +0300 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: Yes, I think someone already mentioned that Haskell Report 2010 says for Data.Char:     showLitChar :: Char -> ShowS         Convert a character to a string using only printable characters, using Haskell source-language escape conventions. For example:         showLitChar '\n' s  =  "\\n" ++ s With the     isPrint :: Char -> Bool     Selects printable Unicode characters (letters, numbers, marks, punctuation, symbols and spaces). being one obvious, yet unused, definition. Also if one looks at the history of GHC, the showLitChar have been essentially unchanged since 2001 when it was introduced to the source tree. So while technically it won't be deviation from the report, I don't think "technically correct" is necessarily correct here. - Oleg On 8.7.2021 19.38, Bardur Arantsson wrote: > On 08/07/2021 17.53, Oleg Grenrus wrote: > > [--snip--] > >> 78 out of 2819 tests failed (35.88s) >> > The use of Show in 'golden' test suites is interesting because Show > doesn't really guarantee any real form of stability in its output. > > I guess Hyrum's Law applies here too. > > Anyway... just an idle observation. Obviously, breaking loads of test > suites is going to be hard to swallow. > > Regards, > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From oleg.grenrus at iki.fi Thu Jul 8 17:20:43 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 8 Jul 2021 20:20:43 +0300 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: <57e48c8c-8186-46f2-5ecc-c90b212e3960@iki.fi> It would also be good to have a summary of of previous discussion OP kindly linked [1], e.g. the comment by David Turner [2] > One of the most visible uses of Show is that it's how values are shown in > GHCi. As mentioned earlier in this thread, if you're teaching in a > non-ASCII language then the user experience is pretty poor. > > On the other hand, I see Show (like .ToString() in C# etc.) as a debugging > tool: not for seriously robust serialisation but useful if you need to dump > a value into a log message or email or similar. And in that situation it's > very useful if it sticks to ASCII: non-ASCII content just isn't resilient > enough to being passed around the network, truncated and generally > mutilated on the way through. > > These are definitely two different concerns and they pull in opposite > directions in this discussion. It's a matter of opinion which you think is > more important. Me, I think the latter, but then I do a lot of logging and > speak a language that fits into  ASCII. YMMV! This proposal is motivated by the first point, but doesn't mention debugging other then > 2. This is an actual annoyance during debugging localized software, or      strings with emojis which I don't agree with. For example look at the failing test case in the pandoc in my previous message. \160 is a non-breaking space, which looks like normal space when rendered normally. I have my share of bad experience with it. So, indeed YMMV. - Oleg [1]: https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122899.html On 8.7.2021 18.53, Oleg Grenrus wrote: > > Here is a simple patch, which I hope is close to what > > 1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_ >    Unicode characters out of the range of ASCII. > > of a proposed change will look like: > >     diff --git a/libraries/base/GHC/Show.hs b/libraries/base/GHC/Show.hs >     index 84077e473b..24569168d4 100644 >     --- a/libraries/base/GHC/Show.hs >     +++ b/libraries/base/GHC/Show.hs >     @@ -364,7 +364,10 @@ showCommaSpace = showString ", " >      -- > showLitChar '\n' s  =  "\\n" ++ s >      -- >      showLitChar                :: Char -> ShowS >     -showLitChar c s | c > '\DEL' =  showChar '\\' (protectEsc isDec > (shows (ord c)) s) >     +showLitChar c s | c > '\DEL' = >     +    if isPrint c >     +    then showChar c s >     +    else  showChar '\\' (protectEsc isDec (shows (ord c)) s) >      showLitChar '\DEL'         s =  showString "\\DEL" s >      showLitChar '\\'           s =  showString "\\\\" s >      showLitChar c s | c >= ' '   =  showChar c s >     @@ -380,6 +383,13 @@ showLitChar c              s =  showString > ('\\' : asciiTab!!ord c) s >              -- I've done manual eta-expansion here, because otherwise > it's >              -- impossible to stop (asciiTab!!ord) getting floated out > as an MFE >      >     +-- Local definition of isPrint to avoid fighting with cycles for now. >     +isPrint                 :: Char -> Bool >     +isPrint    c = iswprint (ord c) /= 0 >     + >     +foreign import ccall unsafe "u_iswprint" >     +  iswprint :: Int -> Int >     + >      showLitString :: String -> ShowS >      -- | Same as 'showLitChar', but for strings >      -- It converts the string to a string using Haskell escape > conventions > > I applied it to ghc-8.10 branch, > >     % _build/stage1/bin/ghc --interactive >     GHCi, version 8.10.5: https://www.haskell.org/ghc/  :? for help >     Prelude> "äiti" >     "äiti" >     Prelude> "мир" >     "мир" >     Prelude> print "мир" >     "мир" >     Prelude> "😀" >     "😀" > > And then run test-suites of aeson, dhall and pandoc. > > Aeson test-suite passed. > Dhall test-suites passed too, > However pandoc testsuite failed: > > 78 out of 2819 tests failed (35.88s) > > An example failure is: > >     3587.md >       #1:                                                            > FAIL (0.01s) >         --- test/command/3587.md >         +++ pandoc -f latex -t native >         +   1 [Para [Str "1 m",Space,Str "is",Space,Str > "equal",Space,Str "to",Space,Str "1000 mm"]] >         -   1 [Para [Str "1\160m",Space,Str "is",Space,Str > "equal",Space,Str "to",Space,Str "1000\160mm"]] > > Str is a constructor of Inline type, and takes Text: data Inline = Str > Text | ... > As discussed on the GHC issue [1], Text and ByteString Show Instances > piggyback on > String instance. Bodigrim said that Text will eventually migrate > to do the same as new Show String [2], so this issue will resurface. > > Please explain the compatibility story. How library writes should write > their code (in test-suites) which rely on Show String or Show Text, such > that they could support GHC base versions (and/or text) versions > on the both sides of this breaking change. > > I agree with Julian that required migration engineering effort across > (even just the open source) ecosystem is non-trivial. > Having a good plan would hopefully make it easier to accept that cost. > > The fact it's a change which is not detectable at compile time > makes me very anxious about this, even I don't disagree with > motivation bits. > I have very little idea if and where I depend on Show String behavior. > > It would also be interesting to see results of test-suites of all > Stackage, but I leave it for someone else to do. > > - Oleg > > [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/20027 > [2]: https://gitlab.haskell.org/ghc/ghc/-/issues/20027#note_363519 > > On 8.7.2021 15.25, Julian Ospald wrote: >> Hi, >> >> I think most seemed to agree on the motivation, but would it be a lot >> of work to ping a few large opensource/industry projects about this >> and get a feel what they think or how much of an expected effort a >> migration would be? I'm afraid that we might take this too lightly >> and possibly cause a lot of engineering effort here. Our expectations >> how or how often people use "show" might or might not be accurate. >> >> I'm aware of e.g. the cardano wallet test suite (open source) and >> other cardano projects that are very large opon source codebases and >> may be affected. >> >> CCing duncan >> >> On July 8, 2021 10:11:28 AM UTC, Kai Ma wrote: >> >> Hi all >> >> Two weeks ago, I proposed “Support Unicode characters in instance Show >> String” [0] in the GHC issue tracker, and chessai asked me to post it >> here for wider feedback. The proposal posted here is edited to reflect >> new ideas proposed and insights accumulated over the days: >> >> 1. (Proposal) Now the proposal itself is now modeled after Python. >> 2. (Alternative Options) Alternative 2 is the original proposal. >> 3. (Downsides) New. About breakage. >> 4. (Prior Art) New. >> 5. (Unresolved Problems) New. Included for discussion. >> >> Even though I wanted to summarize everything here, some insightful >> comments are perhaps not included or misunderstood. These original >> comments can be found at the original feature request. >> >> [0] https://gitlab.haskell.org/ghc/ghc/-/issues/20027 >> >> >> Motivation >> ------------------------------------------------------------------------ >> Unicode has been widely adopted and people around the world rely on >> Unicode to write in their native languages. Haskell, however, has been >> stuck in ASCII, and escape all non-ASCII characters in the String's >> instance of the Showclass, despite the fact that each element of a >> String is typically a Unicode code point, and putStrLn actually works as >> expected. Consider the following examples: >> >> ghci> print "Hello, 世界” >> "Hello, \19990\30028” >> >> ghci> print "Hello, мир” >> "Hello, \1084\1080\1088” >> >> ghci> print "Hello, κόσμος” >> "Hello, \954\972\963\956\959\962” >> >> ghci> "Hello, 世界" -- ghci calls `show`, so string literals are also escaped >> "Hello, \19990\30028” >> >> ghci> "😀" -- Not only human scripts, but also emojis! >> "\128512” >> >> >> This status quo is unsatisfactory for a number of reasons: >> >> 1. Even though it's small, it somehow creates an unwelcoming atmosphere >> for native speakers of languages whose scripts are not representable >> in ASCII. >> 2. This is an actual annoyance during debugging localized software, or >> strings with emojis. >> 3. Following 1, Haskell teachers are forced to use other languages >> instead of the students' mother tongues, or relying on I/O functions >> like putStrLn, creating a rather unnecessary burden. >> 4. Other string types, like Text [1], rely on this Show instance. >> >> Moreover, `read` already can handle Unicode strings today, so relaxing >> constraints on `show` doesn't affect `read . show == id`. >> >> >> Proposal >> ------------------------------------------------------------------------ >> It's proposed here to change the Show instance of String, to achieve the following output: >> >> ghci> print "Hello, 世界” >> "Hello, 世界” >> >> ghci> print "Hello, мир” >> "Hello, мир” >> >> ghci> print "Hello, κόσμος” >> "Hello, κόσμος” >> >> ghci> "Hello, 世界” >> “Hello, 世界” >> >> ghci> "😀” >> “😀" >> >> More concretely, it means: >> >> 1. Modify a few guards in GHC.Show.showLitChar to not escape _readable_ >> Unicode characters out of the range of ASCII. >> 2. Provide a function showEscaped or newtype Escaped = Escaped String to >> obtain the current escaping behavior, in case anyone wants the >> current behavior back. >> >> This proposal isn't about unescaping everything, but only readable >> Unicode characters. u_iswprint (GHC.Unicode.isPrint) seems to do the >> job, and indeed, there was a similar proposal before [2]. In summary, >> the behavior is similar to what Python `repr` does. >> >> >> Alternative Options >> ------------------------------------------------------------------------ >> 1. Always use putStrLn. >> >> This is viable today but unsatisfactory as it requires stdout. In >> some cases, stdout is not accessible, e.g. Telegram or Discord bots. >> >> 2. Don't escape anything. >> >> `show` itself refrains from escaping most of the characters, and let >> ghci do the job instead. >> >> 3. Customize ghci instead. >> >> ghci intercepts output strings and check if they can be converted >> back to readable characters. This potentially allows for better >> compatibility with a variety of strangely behaving terminals, and >> finer-grained user control. >> >> Tom Ellis proposed `-interactive-print`-based solutions in the >> comment section. >> >> 4. A new language extension, e.g. ShowStringUnicode. >> >> Proposed by Julian Ospald. When enabled, readable Unicode characters >> are not escaped, and this is enabled by default by ghci. There are >> concerns about how this would affect cross-module behavior. >> >> >> Downsides >> ------------------------------------------------------------------------ >> This is definitely a breaking change, but the breakage, to our current >> understanding, is limited. >> >> First, use of `show` in production code is discouraged. Even if someone >> really does that, the breakage only happens when one tries to send the >> "serialized" data over wire: >> >> Suppose Machine A `show`-ed a string and saved it into a UTF-8-encoded >> file, and sends it to Machine B, which expects another encoding. This >> would be surprising for those who are used to the old behavior. >> >> Second, though the breakage is not likely to be catastrophic for correct >> production code, test suites could be badly affected, as pointed out by >> Oleg Grenrus and vdukhovni in the comment section. Some test suites >> compare `show` results with expected results. vdukhovni further >> commented that Haskell escapes are not universally supported by >> non-Haskell tools, so the impact would be confined to Haskell. >> >> >> Prior Art >> ------------------------------------------------------------------------ >> Python supports Unicode natively since 3. Python's approach is >> intuitive and capable. Its `repr`, which is equivalent to Haskell's >> `show`, automatically escapes unreadable characters, but leaves readable >> characters unescaped. The criteria of "readable" can be found in >> CPython's code [3]. If we were to realize this proposal, Python could >> be a source of inspiration. >> >> >> Unresolved Problems >> ------------------------------------------------------------------------ >> There are some currently unresolved (not discussed enough) issues. >> >> + Locales. >> >> What if the specified locale does not support Unicode? Hécate >> Moonlight pointed out PEP-538 [4] could be a reference. >> >> + Unicode versions. >> >> Javran Cheng pointed out u_iswprint is generated from a Unicode table, >> which is manually updated. This raises a concern that the definition >> of "printable" characters could change from version to version. >> >> + Definition of "readable". >> >> Unicode already defined "printability". It's good, but it is not >> necessarily what we want here. >> >> - Should we support RTL? >> - Should we design a Haskell-specific definition of readability, to >> avoid Unciode version silently introducing breakage? >> >> (More?) >> >> Some issues here perhaps require better answers to: What is our >> expectation of Show? Where should it be used? Should we expect it to >> break on every Unicode update? >> >> >> [1] https://hackage.haskell.org/package/text-1.2.4.1/docs/src/Data.Text.Show.html#line-37 >> [2] https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html >> [3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Objects/unicodectype.c#L147 >> [4] https://www.python.org/dev/peps/pep-0538/ >> ------------------------------------------------------------------------ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Thu Jul 8 18:17:06 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 8 Jul 2021 20:17:06 +0200 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: I guess this is the perfect time to come up with a Render typeclass that targets end-users rather than satisfying 'read . show = id'. chessai: Could the CLC appoint someone to start working on something? This would be pretty useful to unify the ecosystem (instead of having custom Outputable, Render, etc). Le 08/07/2021 à 18:38, Bardur Arantsson a écrit : > On 08/07/2021 17.53, Oleg Grenrus wrote: > > [--snip--] > >> 78 out of 2819 tests failed (35.88s) >> > The use of Show in 'golden' test suites is interesting because Show > doesn't really guarantee any real form of stability in its output. > > I guess Hyrum's Law applies here too. > > Anyway... just an idle observation. Obviously, breaking loads of test > suites is going to be hard to swallow. > > Regards, > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From lemming at henning-thielemann.de Thu Jul 8 18:25:03 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 8 Jul 2021 20:25:03 +0200 (CEST) Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> On Thu, 8 Jul 2021, Hécate wrote: > I guess this is the perfect time to come up with a Render typeclass that > targets end-users rather than satisfying 'read . show = id'. > > chessai: Could the CLC appoint someone to start working on something? > This would be pretty useful to unify the ecosystem (instead of having > custom Outputable, Render, etc). The question is, whether such a one-fits-all library actually serves the needs of the users. Actually there is already 'printf' which is intended for formatting end-user output. You can write your own PrintfArg instances. Today I am using custom Format classes per project. From ietf-dane at dukhovni.org Thu Jul 8 18:41:41 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 14:41:41 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: On Thu, Jul 08, 2021 at 06:53:38PM +0300, Oleg Grenrus wrote: > An example failure is: > >     3587.md >       #1:                                                            > FAIL (0.01s) >         --- test/command/3587.md >         +++ pandoc -f latex -t native >         +   1 [Para [Str "1 m",Space,Str "is",Space,Str "equal",Space,Str "to",Space,Str "1000 mm"]] >         -   1 [Para [Str "1\160m",Space,Str "is",Space,Str "equal",Space,Str "to",Space,Str "1000\160mm"]] > > Str is a constructor of Inline type, and takes Text: data Inline = Str Text | ... > As discussed on the GHC issue [1], Text and ByteString Show Instances piggyback on > String instance. Bodigrim said that Text will eventually migrate > to do the same as new Show String [2], so this issue will resurface. > > Please explain the compatibility story. How library writes should write > their code (in test-suites) which rely on Show String or Show Text, such > that they could support GHC base versions (and/or text) versions > on the both sides of this breaking change. One possible approach is to apply "show @String . read @String" to normalise expected literal string or text fragments. This is easiest when the expected result is *code* in the test, since the transformation can be applied to the code that's encapsulates the expected value. When there are test *files* that hold the "expected output" of `show` for particular inputs, clearly if `show` changes there can't be a single fixed file that determines the success of the test case. So for reproducible tests, one might have to generate the "expected output" file, by normalising appropropriate fragments as above. Likely a QuasiQuoter can be defined to simplify the task. -- Viktor. From hecate at glitchbra.in Thu Jul 8 19:02:29 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 8 Jul 2021 21:02:29 +0200 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> Message-ID: <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> From what I can see from the various typeclasses that exist: HaTeX's Render : > Class of values that can be transformed to |Text |. core-text's Render : > Types which can be rendered "prettily", that is, formatted by a pretty printer and embossed with beautiful ANSI colours when printed to the terminal. ttc's Render : > The Render type class renders a data type as a textual data type. When defining such classes, people don't seem to enforce much, and on the opposite seem to loosely define the requirements, allowing for ANSI colours for instance. Since we have a mechanism to produce our own instances through newtype wrappers and use Generalised Newtype Deriving or Deriving Via, I don't see much of a problem at this point (of course I only ask to be proven wrong). One example in another language is Rust, which has the Debug and Display traits, Debug being akin to our Show, and Display having the following property > Display is similar to Debug, but Display is for user-facing output, and so cannot be derived. It also interesting to note that these traits belong to a wider family of formatting traits used with their built-in syntax of formatting (Binary, Debug, Lower & Upper Hex, Display, Octal, Write, etc). ––– Henning, you are right, `printf` does exist, and it looks pretty rich in terms of features and customisation. I acknowledge that not using it is mostly a cultural matter, and that it can be fixed by improving our current pedagogical material. If we decide as a community that a typeclass is actually not the proper tool to get away from Show instances, then I will welcome with open arms blog posts & tutorials to guide our community towards this solution, and promote them. Le 08/07/2021 à 20:25, Henning Thielemann a écrit : > > On Thu, 8 Jul 2021, Hécate wrote: > >> I guess this is the perfect time to come up with a Render typeclass >> that targets end-users rather than satisfying 'read . show = id'. >> >> chessai: Could the CLC appoint someone to start working on something? >> This would be pretty useful to unify the ecosystem (instead of having >> custom Outputable, Render, etc). > > The question is, whether such a one-fits-all library actually serves > the needs of the users. Actually there is already 'printf' which is > intended for formatting end-user output. You can write your own > PrintfArg instances. Today I am using custom Format classes per project. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Jul 8 19:18:37 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 15:18:37 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> Message-ID: On Thu, Jul 08, 2021 at 09:02:29PM +0200, Hécate wrote: > From what I can see from the various typeclasses that exist: > Sadly, no new or extant alternative type classes can address the problem, simply because they're NOT `Show`, which is the default interface for inspecting the content of a term, and so is the only one at all likely to be available for the terms of interest. Yes, we should also consider having more type classes for presentation in forms other than compiler-friendly source syntax. Thus, e.g. for DNS data, one might have `Show` for debugging, but `Present` for textual presentations of DNS resource records specified in the multitude of DNS-related RFCs and used as the input syntax in DNS zone files. (Thus a DNS RR would have a binary wire form, an ASCII ByteString presentation form, a `Show` instance that exposes all the constructors, ..., and in the case of domain names also a U-label form for display of domain names to users more comfortable with the native script). Multiple applicable serialisation formats are to be expected, and yet I think that `Show` should still avoid escaping unicode printable text... I don't see a plausible path of getting most libraries that implement `Show` to start implemeting a second parallel class for friendly display. Unless you're thinking overlapping instances: instance Show a => Display a where display = show instance Display String where display = displayString -- Viktor. From tikhon at jelv.is Thu Jul 8 19:21:14 2021 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 8 Jul 2021 12:21:14 -0700 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> Message-ID: Let me second the idea of a Render class—it's something I've wanted repeatedly. There is a clear tension between Show's requirements and human-readable outputs: strings get less readable, we can't summarize/truncate large values, it can't handle functions... At the same time, Show is special because it is ubiquitous. We can derive Show automatically, and it's one of the few classes we can expect almost every data type to implement. Project-specific formatting classes cannot fulfill the same role as Show; they require a non-trivial setup cost (which especially compromises the beginner experience!) and they cannot be used by tools and libraries that are not project-specific. What can a library author do to make their types more readable and usable to their users? Today the best lever is the Show instance, which is why I've seen substantially more "unlawful" Show instances in the wild compared to any other base typeclass. Other languages like Python and Rust have a similar split. I've been doing a fair amount of data sciencey Python lately, and I can tell you that the experience at the normal interpreter (not even talking about Jupyter) is definitely better than in Haskell because things like dataframes are rendered in a human-readable way, formatted as a table and truncated. Having a human-readable class is a non-trivial proposal on its own, and normally I wouldn't want to link it to a different change. In this case, however, there is a clear overlap: a new Render class lets us have two different to-string behaviors in parallel, which solves the problem in a similar way to the other alternatives proposed like a language extension or changing GHCi. On Thu, Jul 8, 2021 at 11:27 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Thu, 8 Jul 2021, Hécate wrote: > > > I guess this is the perfect time to come up with a Render typeclass that > > targets end-users rather than satisfying 'read . show = id'. > > > > chessai: Could the CLC appoint someone to start working on something? > > This would be pretty useful to unify the ecosystem (instead of having > > custom Outputable, Render, etc). > > The question is, whether such a one-fits-all library actually serves the > needs of the users. Actually there is already 'printf' which is intended > for formatting end-user output. You can write your own PrintfArg > instances. Today I am using custom Format classes per > project._______________________________________________ > 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 Thu Jul 8 19:48:28 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 8 Jul 2021 22:48:28 +0300 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> Message-ID: <517459b3-6b37-6d47-2692-35755fcd5e95@iki.fi> GHC Manual: Using a custom interactive printing function [1]     Prelude Data.Char> "foo"     "foo"     Prelude Data.Char> let myprint=putStrLn . map toUpper . show     Prelude Data.Char> :set -interactive-print myprint     Prelude Data.Char> "foo"     "FOO" I remember some people using e.g. pretty-show or pretty-simple packages with great success. No need to change anything in base, just make users aware of a configuration possibility. Also this allows people to actually experiment and come up with good design for a library specifically tailored for interactive printing.  For example, Python's repr implementations are often configurable, as in pandas AFAIU, as one-size doesn't fit all tastes. (Neat case for implicit params in Haskell?) I'm not in support of a new class in base, without prior art. Changing stuff in base is difficult, better to get it (quite) right. I'm undecided on the original proposal itself, I'll wait for OP to answer my questions first, and amend the proposal if needed. [1]: https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/ghci.html#using-a-custom-interactive-printing-function On 8.7.2021 22.21, Tikhon Jelvis wrote: > Let me second the idea of a Render class—it's something I've wanted > repeatedly. There is a clear tension between Show's requirements and > human-readable outputs: strings get less readable, we can't > summarize/truncate large values, it can't handle functions... > > At the same time, Show is special because it is ubiquitous. We can > derive Show automatically, and it's one of the few classes we can > expect almost every data type to implement. Project-specific > formatting classes cannot fulfill the same role as Show; they require > a non-trivial setup cost (which especially compromises the beginner > experience!) and they cannot be used by tools and libraries that are > not project-specific. What can a library author do to make their types > more readable and usable to their users? Today the best lever is the > Show instance, which is why I've seen substantially more "unlawful" > Show instances in the wild compared to any other base typeclass. > > Other languages like Python and Rust have a similar split. I've been > doing a fair amount of data sciencey Python lately, and I can tell you > that the experience at the normal interpreter (not even talking about > Jupyter) is definitely better than in Haskell because things like > dataframes are rendered in a human-readable way, formatted as a table > and truncated. > > Having a human-readable class is a non-trivial proposal on its own, > and normally I wouldn't want to link it to a different change. In this > case, however, there is a clear overlap: a new Render class lets us > have two different to-string behaviors in parallel, which solves the > problem in a similar way to the other alternatives proposed like a > language extension or changing GHCi. > > On Thu, Jul 8, 2021 at 11:27 AM Henning Thielemann > > > wrote: > > > On Thu, 8 Jul 2021, Hécate wrote: > > > I guess this is the perfect time to come up with a Render > typeclass that > > targets end-users rather than satisfying 'read . show = id'. > > > > chessai: Could the CLC appoint someone to start working on > something? > > This would be pretty useful to unify the ecosystem (instead of > having > > custom Outputable, Render, etc). > > The question is, whether such a one-fits-all library actually > serves the > needs of the users. Actually there is already 'printf' which is > intended > for formatting end-user output. You can write your own PrintfArg > instances. Today I am using custom Format classes per > project._______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Thu Jul 8 19:55:39 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 8 Jul 2021 21:55:39 +0200 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> Message-ID: > I don't see a plausible path of getting most libraries that implement > `Show` to start implemeting a second parallel class for friendly display. * Extensive publicity of this typeclass in community (social media, etc) * Stock deriving (implemented by GHC & the CLC) * First-class place in documentation (Documentation Task Force of the HF) * Coordinated effort with popular libraries to implement its adoption (CLC + stakeholders) * Maybe a code-modding script using retrie . We will have to work as a community on that one but I am convinced that this is doable. Le 08/07/2021 à 21:18, Viktor Dukhovni a écrit : > On Thu, Jul 08, 2021 at 09:02:29PM +0200, Hécate wrote: >> From what I can see from the various typeclasses that exist: >> > Sadly, no new or extant alternative type classes can address the > problem, simply because they're NOT `Show`, which is the default > interface for inspecting the content of a term, and so is the only > one at all likely to be available for the terms of interest. > > Yes, we should also consider having more type classes for presentation > in forms other than compiler-friendly source syntax. > > Thus, e.g. for DNS data, one might have `Show` for debugging, but > `Present` for textual presentations of DNS resource records specified in > the multitude of DNS-related RFCs and used as the input syntax in DNS > zone files. (Thus a DNS RR would have a binary wire form, an ASCII > ByteString presentation form, a `Show` instance that exposes all the > constructors, ..., and in the case of domain names also a U-label > form for display of domain names to users more comfortable with the > native script). > > Multiple applicable serialisation formats are to be expected, and yet I > think that `Show` should still avoid escaping unicode printable text... > > I don't see a plausible path of getting most libraries that implement > `Show` to start implemeting a second parallel class for friendly > display. > > Unless you're thinking overlapping instances: > > instance Show a => Display a where > display = show > > instance Display String where > display = displayString > -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Jul 8 19:58:32 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 8 Jul 2021 21:58:32 +0200 (CEST) Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <517459b3-6b37-6d47-2692-35755fcd5e95@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <517459b3-6b37-6d47-2692-35755fcd5e95@iki.fi> Message-ID: <59a4cddd-b4cb-6521-5c39-de7d98dfc71b@henning-thielemann.de> On Thu, 8 Jul 2021, Oleg Grenrus wrote: > GHC Manual: Using a custom interactive printing function [1] > >     Prelude Data.Char> "foo" >     "foo" >     Prelude Data.Char> let myprint=putStrLn . map toUpper . show >     Prelude Data.Char> :set -interactive-print myprint >     Prelude Data.Char> "foo" >     "FOO" > > I remember some people using e.g. pretty-show or pretty-simple packages > with great success. That's great! > No need to change anything in base, just make users aware of a > configuration possibility. I missed that feature, too. From lemming at henning-thielemann.de Thu Jul 8 20:01:00 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 8 Jul 2021 22:01:00 +0200 (CEST) Subject: custom Format class (Was: [RFC] Support Unicode characters in instance Show String) In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> Message-ID: On Thu, 8 Jul 2021, Hécate wrote: > > I don't see a plausible path of getting most libraries that implement > > `Show` to start implemeting a second parallel class for friendly display. > > * Extensive publicity of this typeclass in community (social media, etc) > * Stock deriving (implemented by GHC & the CLC) That works for Show, because Show is expected to display Haskell code. But how would you automatically derive human readable text from an arbitrary algebraic data type? > * First-class place in documentation (Documentation Task Force of the HF) > * Coordinated effort with popular libraries to implement its adoption (CLC + stakeholders) > * Maybe a code-modding script using retrie. > > We will have to work as a community on that one but I am convinced that this is doable. From ietf-dane at dukhovni.org Thu Jul 8 20:00:37 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 16:00:37 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <517459b3-6b37-6d47-2692-35755fcd5e95@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <517459b3-6b37-6d47-2692-35755fcd5e95@iki.fi> Message-ID: On Thu, Jul 08, 2021 at 10:48:28PM +0300, Oleg Grenrus wrote: > GHC Manual: Using a custom interactive printing function [1] > >     Prelude Data.Char> "foo" >     "foo" >     Prelude Data.Char> let myprint=putStrLn . map toUpper . show >     Prelude Data.Char> :set -interactive-print myprint >     Prelude Data.Char> "foo" >     "FOO" > > I remember some people using e.g. pretty-show or pretty-simple packages > with great success. > > No need to change anything in base, just make users aware of a configuration > possibility. This is NOT viable, not all escapes are valid to unescape after the fact in a print function. Which pieces of the `show` output are escaped unicode characters, and which are not depends on the original data type that got serialised to a given `String`. For example, in a `ByteString` the octet '\xFC' should display as '\252', while in a `String` or `Text` U+00FC should display as 'ü'. Thus, there is no correct unescape function for the string "M\\252ller", it could be "Müller", or not... -- Viktor. From hecate at glitchbra.in Thu Jul 8 21:07:36 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 8 Jul 2021 23:07:36 +0200 Subject: custom Format class (Was: [RFC] Support Unicode characters in instance Show String) In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> Message-ID: <6a6005a3-9e6e-9892-6ff5-25356769e466@glitchbra.in> You can literally piggyback on Show's machinery for generic deriving? I don't understand the issue here. If the output is not easily-read by humans, then implement the instance yourself? Le 08/07/2021 à 22:01, Henning Thielemann a écrit : > > On Thu, 8 Jul 2021, Hécate wrote: > >> > I don't see a plausible path of getting most libraries that implement >> > `Show` to start implemeting a second parallel class for friendly >> display. >> >> * Extensive publicity of this typeclass in community (social media, etc) >> * Stock deriving (implemented by GHC & the CLC) > > That works for Show, because Show is expected to display Haskell code. > But how would you automatically derive human readable text from an > arbitrary algebraic data type? > >> * First-class place in documentation (Documentation Task Force of the >> HF) >> * Coordinated effort with popular libraries to implement its adoption >> (CLC + stakeholders) >> * Maybe a code-modding script using retrie. >> >> We will have to work as a community on that one but I am convinced >> that this is doable. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From ietf-dane at dukhovni.org Thu Jul 8 21:37:51 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Jul 2021 17:37:51 -0400 Subject: custom Format class (Was: [RFC] Support Unicode characters in instance Show String) In-Reply-To: <6a6005a3-9e6e-9892-6ff5-25356769e466@glitchbra.in> References: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> <6a6005a3-9e6e-9892-6ff5-25356769e466@glitchbra.in> Message-ID: On Thu, Jul 08, 2021 at 11:07:36PM +0200, Hécate wrote: > You can literally piggyback on Show's machinery for generic deriving? > I don't understand the issue here. If the output is not easily-read > by humans, then implement the instance yourself? Indeed a `Render` (module bikeshedding the name) class can be derived in much the same way as `Show`, but might not be as friendly in many cases, because generically it would emit constructor and field names that might be omitted in a more friendly rendition of the structure. So `Render` would warrant a specialised instance in more cases. One might perhaps `render` a date in ISO 8601 format, skipping the constructor names. If, for example, it was decided that a DNS Resource Record should `render` to its RFC Presentation form, then one might want to render a list of resource records (an RRSet) by just joining newline separated strings: > putStrLn $ render $ [ { rname = "example.com." , rclass = IN , rdata = RData { T_A "192.0.2.1" } , { rname = "example.com." , rclass = IN , rdata = RData { T_A "127.0.0.1" } ] example.com. IN A 192.0.2.1 example.com. IN A 127.0.0.1 > rather than as: ["example.com. IN A 192.0.2.1","example.com. IN A 127.0.0.1"] taking advantage of the possibility of custom presentation of lists. It may be worth noting that on a smaller, incremental scale, once `Render` is established, there would be incentives to fix some of the non-lawful `Show` instances, which would introduce transient breakage for the consumers of the affected packages. -- Viktor. From hecate at glitchbra.in Thu Jul 8 21:48:50 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 8 Jul 2021 23:48:50 +0200 Subject: custom Format class (Was: [RFC] Support Unicode characters in instance Show String) In-Reply-To: References: <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> <9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de> <698d767e-fcd0-6430-e52a-b60d63926f08@glitchbra.in> <6a6005a3-9e6e-9892-6ff5-25356769e466@glitchbra.in> Message-ID: > It may be worth noting that on a smaller, incremental scale, once > `Render` is established, there would be incentives to fix some of > the non-lawful `Show` instances, which would introduce transient > breakage for the consumers of the affected packages. GHC releases frequently fix situations where code that was previously accepted will be rejected, so it feels normal that we decide to fix unlawful Show instances while providing a more adapted solution for human-readable outputs. :) Le 08/07/2021 à 23:37, Viktor Dukhovni a écrit : > On Thu, Jul 08, 2021 at 11:07:36PM +0200, Hécate wrote: > >> You can literally piggyback on Show's machinery for generic deriving? >> I don't understand the issue here. If the output is not easily-read >> by humans, then implement the instance yourself? > Indeed a `Render` (module bikeshedding the name) class can be derived > in much the same way as `Show`, but might not be as friendly in many > cases, because generically it would emit constructor and field names > that might be omitted in a more friendly rendition of the structure. > > So `Render` would warrant a specialised instance in more cases. > > One might perhaps `render` a date in ISO 8601 format, skipping the > constructor names. > > If, for example, it was decided that a DNS Resource Record should > `render` to its RFC Presentation form, then one might want to render a > list of resource records (an RRSet) by just joining newline separated > strings: > > > putStrLn $ render $ > [ { rname = "example.com." > , rclass = IN > , rdata = RData { T_A "192.0.2.1" } > , { rname = "example.com." > , rclass = IN > , rdata = RData { T_A "127.0.0.1" } ] > example.com. IN A 192.0.2.1 > example.com. IN A 127.0.0.1 > > > > rather than as: > > ["example.com. IN A 192.0.2.1","example.com. IN A 127.0.0.1"] > > taking advantage of the possibility of custom presentation of lists. > > It may be worth noting that on a smaller, incremental scale, once > `Render` is established, there would be incentives to fix some of > the non-lawful `Show` instances, which would introduce transient > breakage for the consumers of the affected packages. > -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From travis.cardwell at extrema.is Thu Jul 8 23:04:40 2021 From: travis.cardwell at extrema.is (Travis Cardwell) Date: Fri, 9 Jul 2021 08:04:40 +0900 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: On Fri, Jul 9, 2021 at 3:18 AM Hécate wrote: > I guess this is the perfect time to come up with a Render typeclass that > targets end-users rather than satisfying 'read . show = id'. This is the primary motivation of the TTC (Textual Type Classes) library: . It provides a Render type class that is analogous to Show and a Parse type class that is analogous to Read. No instances are declared so that users of the library can implement instances as required for each application, but default instances for core types are available. Travis From ruben.astud at gmail.com Fri Jul 9 15:17:45 2021 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Fri, 9 Jul 2021 11:17:45 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: <6b807831-e20e-76a9-4a6a-cebf99fb458d@gmail.com> On 08-07-21 19:04, Travis Cardwell via Libraries wrote: > This is the primary motivation of the TTC (Textual Type Classes) > library: . > > It provides a Render type class that is analogous to Show and a Parse > type class that is analogous to Read. No instances are declared so that > users of the library can implement instances as required for each > application, but default instances for core types are available. Not related to the main point of the thread, but we really need a way to signal certain libraries as the "go to solution" for a problem without including them in "base". A note on the Show/Read class documentation saying that the best solution for "showing" human text is certain library would be great. -- -- Rubén -- pgp: 4EE9 28F7 932E F4AD From ietf-dane at dukhovni.org Fri Jul 9 17:05:37 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Jul 2021 13:05:37 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <0f67eb49-f28d-af20-2754-e29e945b6c23@iki.fi> Message-ID: On Fri, Jul 09, 2021 at 08:04:40AM +0900, Travis Cardwell via Libraries wrote: > On Fri, Jul 9, 2021 at 3:18 AM Hécate wrote: > > I guess this is the perfect time to come up with a Render typeclass that > > targets end-users rather than satisfying 'read . show = id'. > > This is the primary motivation of the TTC (Textual Type Classes) > library: . > > It provides a Render type class that is analogous to Show and a Parse > type class that is analogous to Read. No instances are declared so that > users of the library can implement instances as required for each > application, but default instances for core types are available. One promising feature of this is that the target type is not restricted to just `String`, but rather `Render` produces a `Textual` value, which can be a String, Text, ByteString, or a Text or Binary `builder`. I would prefer to also see a ByteString `Builder` as an option, but the high level design feels sound. -- Viktor. From ietf-dane at dukhovni.org Sun Jul 11 04:01:11 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 11 Jul 2021 00:01:11 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> Message-ID: On Thu, Jul 08, 2021 at 06:11:28PM +0800, Kai Ma wrote: > > It's proposed here to change the Show instance of String, to achieve the following output: > > ghci> print "Hello, 世界” > "Hello, 世界” > > ghci> print "Hello, мир” > "Hello, мир” > > ghci> print "Hello, κόσμος” > "Hello, κόσμος” > > ghci> "Hello, 世界” > “Hello, 世界” > > ghci> "😀” > “😀" Another possibility is to extend the `Show` class with two new methods and their default implementations: class Show where ... showsPrecUnicode :: Int -> a -> ShowS showsPrecUnicode = showsPrec showListUnicode :: [a] -> ShowS showListUnicode = showList showUnicode :: Show a => a -> String showUnicode x = showsPrecUnicode 0 x "" at which point a small number of classes can override `showUnicode` and `showListUnicode`: instance Show a => Show [a] where showsPrec _ = showList showsPrecUnicode = showListUnicode instance Show Char where showsPrecUnicode = ... -- Unicode char showListUnicode = ... -- Unicode string instance Show Text where showsPrecUnicode = ... -- Unicode text Once these are implemented, "ghci" can be modified to instead used `showUnicode`, rather than `show`, with no new incompatibilities elsewhere. We can also introduce `uprint = putStrLn . showUnicode`, ... This would still require explicit opt-in to use the Unicode show, but it would be available for all `Show` instances, and used by default in "ghci". It would still be a good idea to implement `Render`, which is a related but separate concern. -- Viktor. From oleg.grenrus at iki.fi Sun Jul 11 12:11:02 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 11 Jul 2021 15:11:02 +0300 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> Message-ID: <4eeeb629-7061-8aae-f67a-e9a49e6527d6@iki.fi> This is tricky design. Any instance in the composition which doesn't define showsPrecUnicode will ruin formatting of inner Strings. Maybe it's not as bad as in aeson* as most Show instances are derived. (But not Show1 etc.) * The problem with aeson is ToJSON class having toValue (old method), and toEncoding, which is fast but which default implementation is using slower toValue.    Thus `instance ToJSON MyType` derived generally silently ruins the performance. It might be better to not define default implementation for showsPrecUnicode (cause most instances are derived), as though it will break explicitly written instances, but fixing them is straigh-forward. (GHC developers use head.hackage will hate this option though). I'm not sure this is any better then separate class, and whether two type-classes (either actually or two-in-one) is a good idea. - Oleg On 11.7.2021 7.01, Viktor Dukhovni wrote: > On Thu, Jul 08, 2021 at 06:11:28PM +0800, Kai Ma wrote: > >> It's proposed here to change the Show instance of String, to achieve the following output: >> >> ghci> print "Hello, 世界” >> "Hello, 世界” >> >> ghci> print "Hello, мир” >> "Hello, мир” >> >> ghci> print "Hello, κόσμος” >> "Hello, κόσμος” >> >> ghci> "Hello, 世界” >> “Hello, 世界” >> >> ghci> "😀” >> “😀" > Another possibility is to extend the `Show` class with two new methods > and their default implementations: > > class Show where > ... > showsPrecUnicode :: Int -> a -> ShowS > showsPrecUnicode = showsPrec > > showListUnicode :: [a] -> ShowS > showListUnicode = showList > > showUnicode :: Show a => a -> String > showUnicode x = showsPrecUnicode 0 x "" > > at which point a small number of classes can override `showUnicode` > and `showListUnicode`: > > instance Show a => Show [a] where > showsPrec _ = showList > showsPrecUnicode = showListUnicode > > instance Show Char where > showsPrecUnicode = ... -- Unicode char > showListUnicode = ... -- Unicode string > > instance Show Text where > showsPrecUnicode = ... -- Unicode text > > Once these are implemented, "ghci" can be modified to instead used > `showUnicode`, rather than `show`, with no new incompatibilities > elsewhere. > > We can also introduce `uprint = putStrLn . showUnicode`, ... > > This would still require explicit opt-in to use the Unicode show, > but it would be available for all `Show` instances, and used by > default in "ghci". > > It would still be a good idea to implement `Render`, which is a related > but separate concern. > From ietf-dane at dukhovni.org Sun Jul 11 16:46:42 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 11 Jul 2021 12:46:42 -0400 Subject: [RFC] Support Unicode characters in instance Show String In-Reply-To: <4eeeb629-7061-8aae-f67a-e9a49e6527d6@iki.fi> References: <09808E7B-6AF7-46C6-8E8D-35E1FD0EF121@gmail.com> <4eeeb629-7061-8aae-f67a-e9a49e6527d6@iki.fi> Message-ID: On Sun, Jul 11, 2021 at 03:11:02PM +0300, Oleg Grenrus wrote: > This is tricky design. Any instance in the composition which doesn't > define showsPrecUnicode will ruin formatting of inner Strings. > Maybe it's not as bad as in aeson* as most Show instances are derived. > (But not Show1 etc.) Yes, if a manually defined instance uses `show` on a substructure that contains strings, the strings will be rendered with unicode characters escaped. As you note, the ability to retain Unicode representations of nested structures would depend on either derived instances or tweaks to manual instances to also define the Unicode-preserving methods. This would not be perfect, but would avoid disruption, and so should have a much easier path to deployment. Over time the instances that fail to preserve Unicode strings can be refined. If tests in various packages are incrementally changed to use `showUnicode` to verify expected output, eventually we may be able to make `show` also Unicode-preserving, with much less disruption. This can provide a migration path over O(10yr) from the status quo to a Unicode-friendly `show`. -- Viktor. From david.feuer at gmail.com Fri Jul 16 20:55:17 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 16 Jul 2021 16:55:17 -0400 Subject: Proposal: make liftF a method of MonadFree Message-ID: We have class Monad m => MonadFree f m | m -> f where wrap :: f (m a) -> m a liftF :: (Functor f, MonadFree f m) => f a -> m a liftF = wrap . fmap pure I propose we change this to class Monad m => MonadFree f m | m -> f where wrap :: f (m a) -> m a liftF :: f a -> m a default liftF :: Functor f => f a -> m a liftF = wrap . fmap pure and add a function defaultWrap :: MonadFree f m => f (m a) -> m a defaultWrap = join . liftF This change is not strictly backwards compatible. Some instances might, hypothetically, have to add a Functor constraint. For example, the classic Control.Monad.Free and Control.Monad.Trans.Free would need them. However, those instances already have (currently redundant) Functor constraints, so that doesn't seem like a big deal. An alternative would be to hew more strictly to backwards compatibility by placing a Functor f constraint on liftF. This seems a bit sad for "freer" instances that don't need it. For example, we have newtype FT f m a = FT { runFT :: forall r. (a -> m r) -> (forall x. (x -> m r) -> f x -> m r) -> m r } for which liftF :: f a -> FT f m a liftF fa = FT $ \pur bndf -> bndf pur fa Pull request at https://github.com/ekmett/free/pull/208 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Jul 16 22:52:24 2021 From: david.feuer at gmail.com (David Feuer) Date: Fri, 16 Jul 2021 18:52:24 -0400 Subject: Proposal: make liftF a method of MonadFree In-Reply-To: References: Message-ID: Another flavor would be to leave liftF alone and add a method that does the same thing with a different name. This would preserve performance characteristics for instances like FT, for situations where the current implementation is faster. On Fri, Jul 16, 2021, 4:55 PM David Feuer wrote: > We have > > class Monad m => MonadFree f m | m -> f where > wrap :: f (m a) -> m a > > liftF :: (Functor f, MonadFree f m) => f a -> m a > liftF = wrap . fmap pure > > I propose we change this to > > class Monad m => MonadFree f m | m -> f where > wrap :: f (m a) -> m a > > liftF :: f a -> m a > default liftF :: Functor f => f a -> m a > liftF = wrap . fmap pure > > and add a function > > defaultWrap :: MonadFree f m => f (m a) -> m a > defaultWrap = join . liftF > > This change is not strictly backwards compatible. Some instances might, > hypothetically, have to add a Functor constraint. For example, the classic > Control.Monad.Free and Control.Monad.Trans.Free would need them. However, > those instances already have (currently redundant) Functor constraints, so > that doesn't seem like a big deal. > > An alternative would be to hew more strictly to backwards compatibility by > placing a Functor f constraint on liftF. This seems a bit sad for "freer" > instances that don't need it. For example, we have > > newtype FT f m a = FT > { runFT :: forall r. (a -> m r) -> (forall x. (x -> m r) -> f x -> m r) > -> m r } > > for which > > liftF :: f a -> FT f m a > liftF fa = FT $ \pur bndf -> bndf pur fa > > Pull request at https://github.com/ekmett/free/pull/208 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Jul 17 12:32:04 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 17 Jul 2021 08:32:04 -0400 Subject: Proposal: make liftF a method of MonadFree In-Reply-To: References: Message-ID: What about having the class head be Monad m, Functor f=> … MonadFree f m .. ? Is the motivation here to have a more performant liftF? What are some examples of more efficient implementations for current instances and what’s the performance delta? On Fri, Jul 16, 2021 at 6:53 PM David Feuer wrote: > Another flavor would be to leave liftF alone and add a method that does > the same thing with a different name. This would preserve performance > characteristics for instances like FT, for situations where the current > implementation is faster. > > On Fri, Jul 16, 2021, 4:55 PM David Feuer wrote: > >> We have >> >> class Monad m => MonadFree f m | m -> f where >> wrap :: f (m a) -> m a >> >> liftF :: (Functor f, MonadFree f m) => f a -> m a >> liftF = wrap . fmap pure >> >> I propose we change this to >> >> class Monad m => MonadFree f m | m -> f where >> wrap :: f (m a) -> m a >> >> liftF :: f a -> m a >> default liftF :: Functor f => f a -> m a >> liftF = wrap . fmap pure >> >> and add a function >> >> defaultWrap :: MonadFree f m => f (m a) -> m a >> defaultWrap = join . liftF >> >> This change is not strictly backwards compatible. Some instances might, >> hypothetically, have to add a Functor constraint. For example, the classic >> Control.Monad.Free and Control.Monad.Trans.Free would need them. However, >> those instances already have (currently redundant) Functor constraints, so >> that doesn't seem like a big deal. >> >> An alternative would be to hew more strictly to backwards compatibility >> by placing a Functor f constraint on liftF. This seems a bit sad for >> "freer" instances that don't need it. For example, we have >> >> newtype FT f m a = FT >> { runFT :: forall r. (a -> m r) -> (forall x. (x -> m r) -> f x -> m >> r) -> m r } >> >> for which >> >> liftF :: f a -> FT f m a >> liftF fa = FT $ \pur bndf -> bndf pur fa >> >> Pull request at https://github.com/ekmett/free/pull/208 >> > _______________________________________________ > 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 Sat Jul 17 14:20:15 2021 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 17 Jul 2021 07:20:15 -0700 Subject: Proposal: make liftF a method of MonadFree In-Reply-To: References: Message-ID: On Sat, Jul 17, 2021 at 5:32 AM Carter Schonwald wrote: > What about having the class head be > > Monad m, Functor f=> … MonadFree f m .. > ? > Requiring f to be a Functor would be too strong. Plenty of these are not. > Is the motivation here to have a more performant liftF? > > What are some examples of more efficient implementations for current > instances and what’s the performance delta? > Often the difference can be a walk of the entire structure. I'm not allergic to the idea of just adding the method to the class as proposed, it already has a superclass, so it is already a record internally, etc. > On Fri, Jul 16, 2021 at 6:53 PM David Feuer wrote: > >> Another flavor would be to leave liftF alone and add a method that does >> the same thing with a different name. This would preserve performance >> characteristics for instances like FT, for situations where the current >> implementation is faster. >> >> On Fri, Jul 16, 2021, 4:55 PM David Feuer wrote: >> >>> We have >>> >>> class Monad m => MonadFree f m | m -> f where >>> wrap :: f (m a) -> m a >>> >>> liftF :: (Functor f, MonadFree f m) => f a -> m a >>> liftF = wrap . fmap pure >>> >>> I propose we change this to >>> >>> class Monad m => MonadFree f m | m -> f where >>> wrap :: f (m a) -> m a >>> >>> liftF :: f a -> m a >>> default liftF :: Functor f => f a -> m a >>> liftF = wrap . fmap pure >>> >>> and add a function >>> >>> defaultWrap :: MonadFree f m => f (m a) -> m a >>> defaultWrap = join . liftF >>> >>> This change is not strictly backwards compatible. Some instances might, >>> hypothetically, have to add a Functor constraint. For example, the classic >>> Control.Monad.Free and Control.Monad.Trans.Free would need them. However, >>> those instances already have (currently redundant) Functor constraints, so >>> that doesn't seem like a big deal. >>> >>> An alternative would be to hew more strictly to backwards compatibility >>> by placing a Functor f constraint on liftF. This seems a bit sad for >>> "freer" instances that don't need it. For example, we have >>> >>> newtype FT f m a = FT >>> { runFT :: forall r. (a -> m r) -> (forall x. (x -> m r) -> f x -> m >>> r) -> m r } >>> >>> for which >>> >>> liftF :: f a -> FT f m a >>> liftF fa = FT $ \pur bndf -> bndf pur fa >>> >>> Pull request at https://github.com/ekmett/free/pull/208 >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Jul 17 14:50:40 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 17 Jul 2021 10:50:40 -0400 Subject: Proposal: make liftF a method of MonadFree In-Reply-To: References: Message-ID: Ok cool. These both make sense to me then. and sound like a good idea! It would be nice to know what public instances would break as is with the change: and if they do, how many need the extra constraint david suggests on their instance. As long as those are easy to rectify and we get such a nice asymptotic win, this sounds great! An idea I’ve mentioned before is that a simple "fast" way to to approximate / see where things might be impacted is the following work flow: > cabal list --simple | awk '{print ($1)}' | uniq | time xargs -P20 -n1 cabal get and then grep around for uses of MonadFree to see what might be impacted by such a change its a really simple way to evaluate an "over approximation" in terms of usage of an interface, or namespace/syntax (by no means complete, esp since the above only pulls down the most recent version of every package), but also pretty zippy all things considered On Sat, Jul 17, 2021 at 10:20 AM Edward Kmett wrote: > > On Sat, Jul 17, 2021 at 5:32 AM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> What about having the class head be >> >> Monad m, Functor f=> … MonadFree f m .. >> ? >> > > Requiring f to be a Functor would be too strong. Plenty of these are not. > > >> Is the motivation here to have a more performant liftF? >> >> What are some examples of more efficient implementations for current >> instances and what’s the performance delta? >> > > Often the difference can be a walk of the entire structure. I'm not > allergic to the idea of just adding the method to the class as proposed, it > already has a superclass, so it is already a record internally, etc. > > > >> On Fri, Jul 16, 2021 at 6:53 PM David Feuer >> wrote: >> >>> Another flavor would be to leave liftF alone and add a method that does >>> the same thing with a different name. This would preserve performance >>> characteristics for instances like FT, for situations where the current >>> implementation is faster. >>> >>> On Fri, Jul 16, 2021, 4:55 PM David Feuer wrote: >>> >>>> We have >>>> >>>> class Monad m => MonadFree f m | m -> f where >>>> wrap :: f (m a) -> m a >>>> >>>> liftF :: (Functor f, MonadFree f m) => f a -> m a >>>> liftF = wrap . fmap pure >>>> >>>> I propose we change this to >>>> >>>> class Monad m => MonadFree f m | m -> f where >>>> wrap :: f (m a) -> m a >>>> >>>> liftF :: f a -> m a >>>> default liftF :: Functor f => f a -> m a >>>> liftF = wrap . fmap pure >>>> >>>> and add a function >>>> >>>> defaultWrap :: MonadFree f m => f (m a) -> m a >>>> defaultWrap = join . liftF >>>> >>>> This change is not strictly backwards compatible. Some instances might, >>>> hypothetically, have to add a Functor constraint. For example, the classic >>>> Control.Monad.Free and Control.Monad.Trans.Free would need them. However, >>>> those instances already have (currently redundant) Functor constraints, so >>>> that doesn't seem like a big deal. >>>> >>>> An alternative would be to hew more strictly to backwards compatibility >>>> by placing a Functor f constraint on liftF. This seems a bit sad for >>>> "freer" instances that don't need it. For example, we have >>>> >>>> newtype FT f m a = FT >>>> { runFT :: forall r. (a -> m r) -> (forall x. (x -> m r) -> f x -> m >>>> r) -> m r } >>>> >>>> for which >>>> >>>> liftF :: f a -> FT f m a >>>> liftF fa = FT $ \pur bndf -> bndf pur fa >>>> >>>> Pull request at https://github.com/ekmett/free/pull/208 >>>> >>> _______________________________________________ >>> 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 harendra.kumar at gmail.com Sun Jul 18 13:49:24 2021 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 18 Jul 2021 19:19:24 +0530 Subject: Question about withMVar Message-ID: The documentation of withMVar (in Control.Concurrent.MVar module of base package) says: {-| 'withMVar' is an exception-safe wrapper for operating on the contents of an 'MVar'. This operation is exception-safe: it will replace the original contents of the 'MVar' if an exception is raised (see "Control.Exception"). However, it is only atomic if there are no other producers for this 'MVar'.-}withMVar :: MVar a -> (a -> IO b) -> IO bwithMVar m io = mask $ \restore -> do a <- takeMVar m b <- restore (io a) `onException` putMVar m a putMVar m a return b Can someone shed some light on what is meant by the statement - "However, it is only atomic if there are no other producers for this 'MVar'."? I hope this is the right mailing list for this question. Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jul 18 14:01:06 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 18 Jul 2021 10:01:06 -0400 Subject: Question about withMVar In-Reply-To: References: Message-ID: It's pointing out that it's possible that after it takes the MVar some other thread could put the MVar. That could cause it to block, or could violate assumptions about how the MVar value changes. The basic rule is that whenever you're using an MVar you need all the threads to agree to some particular discipline. Most commonly, and best supported by the API, is "take, then put". However, there are other patterns, the most important of which is probably "put once", used to communicate thread completion. On Sun, Jul 18, 2021, 9:49 AM Harendra Kumar wrote: > The documentation of withMVar (in Control.Concurrent.MVar module of base > package) says: > > {-| 'withMVar' is an exception-safe wrapper for operating on the contents of an 'MVar'. This operation is exception-safe: it will replace the original contents of the 'MVar' if an exception is raised (see "Control.Exception"). However, it is only atomic if there are no other producers for this 'MVar'.-}withMVar :: MVar a -> (a -> IO b) -> IO bwithMVar m io = mask $ \restore -> do a <- takeMVar m b <- restore (io a) `onException` putMVar m a putMVar m a return b > > Can someone shed some light on what is meant by the statement - > "However, it is only atomic if there are no other producers for this 'MVar'."? > > I hope this is the right mailing list for this question. > > Thanks, > Harendra > > _______________________________________________ > 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 matthewtpickering at gmail.com Sun Jul 18 14:01:48 2021 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 18 Jul 2021 15:01:48 +0100 Subject: Question about withMVar In-Reply-To: References: Message-ID: This recent commit attempted to clarify the situation. https://gitlab.haskell.org/ghc/ghc/-/commit/bb8e0df8f4187a4f4d0788dd3da3ef6f9268d378 Does that help? On Sun, Jul 18, 2021 at 2:49 PM Harendra Kumar wrote: > > The documentation of withMVar (in Control.Concurrent.MVar module of base package) says: > > {-| > 'withMVar' is an exception-safe wrapper for operating on the contents > of an 'MVar'. This operation is exception-safe: it will replace the > original contents of the 'MVar' if an exception is raised (see > "Control.Exception"). However, it is only atomic if there are no > other producers for this 'MVar'. > -} > withMVar :: MVar a -> (a -> IO b) -> IO b > withMVar m io = > mask $ \restore -> do > a <- takeMVar m > b <- restore (io a) `onException` putMVar m a > putMVar m a > return b > > Can someone shed some light on what is meant by the statement - > "However, it is only atomic if there are no other producers for this 'MVar'."? > > I hope this is the right mailing list for this question. > > Thanks, > Harendra > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From emertens at gmail.com Sun Jul 18 18:00:40 2021 From: emertens at gmail.com (Eric Mertens) Date: Sun, 18 Jul 2021 11:00:40 -0700 Subject: Question about withMVar In-Reply-To: References: Message-ID: The action is atomic as long as while one thread is using withMVar another thread isn't using putMVar On Sun, Jul 18, 2021 at 6:49 AM Harendra Kumar wrote: > The documentation of withMVar (in Control.Concurrent.MVar module of base > package) says: > > {-| 'withMVar' is an exception-safe wrapper for operating on the contents of an 'MVar'. This operation is exception-safe: it will replace the original contents of the 'MVar' if an exception is raised (see "Control.Exception"). However, it is only atomic if there are no other producers for this 'MVar'.-}withMVar :: MVar a -> (a -> IO b) -> IO bwithMVar m io = mask $ \restore -> do a <- takeMVar m b <- restore (io a) `onException` putMVar m a putMVar m a return b > > Can someone shed some light on what is meant by the statement - > "However, it is only atomic if there are no other producers for this 'MVar'."? > > I hope this is the right mailing list for this question. > > Thanks, > Harendra > > _______________________________________________ > 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 andrew.lelechenko at gmail.com Mon Jul 19 19:15:09 2021 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Mon, 19 Jul 2021 20:15:09 +0100 Subject: [RFC] Semantics of size hints in text package Message-ID: <7F051F12-C9DC-405F-8197-525F02191829@gmail.com> I’d like to gather a feedback on the semantics of size hints in `text` package, as outlined at https://github.com/haskell/text/issues/356 . Best regards, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: