- Libraries - Haskell.org

Lookup variant for IntMap
by Callan McGill 16 Aug '21

16 Aug '21

Hi all, I recently noticed that lookup for IntMap favours searches that can fast-fail - if instead we are in a situation where lookups are mostly successful, then this can be wasteful (see this issue for details: https://github.com/haskell/containers/issues/794) Since both versions are useful, it would be best to offer users both variants. I wondered if people on this list had any suggestions for a name for the new function? David Feuer also wondered which of these two behaviours should be the default. My inclination is for it to be the current version which fails faster (this also guarantees no unfortunate regressions) but it would be useful to run more substantial real-world benchmarks to figure that out (if anyone has any suggestions then do let me know). Best wishes, Callan

3 2

How to use Read for Data.Version
by Andreas Abel 14 Aug '21

14 Aug '21

How is the parser for Data.Version supposed to work? ```haskell import Data.Version readVersion :: String -> Version readVersion = read main :: IO () main = print $ readVersion "8.10.5" -- *** Exception: Prelude.read: no parse ``` P.S.: Maintainer libraries(a)haskell.org

4 4

State of the CLC
by Emily Pillmore 12 Aug '21

12 Aug '21

Hello Haskell! The Core Libraries Committee is undergoing some changes at the moment, and I'd like to fill everyone in about the state of the CLC, what's happening behind the scenes, and what we hope to accomplish in the future. It's no secret that the CLC hasn't been as active as of late, and hopefully this post will serve to clear that up and invite new interest in our plans going forward. ## History of the CLC Originally, the CLC was created to steward the `base` library and review changes to it, which no one was really empowered to do before its inception. In particular, this was extremely helpful in stewarding large changesets such as the FTP and AMP proposals. With the success of these proposal implementations, the responsibilities and headcount of the CLC grew to the point where they were asked to steward not just `base`, but also a collection of "mission critical" libraries that GHC relied upon in order to function. Slowly, the number of these packages grew to 13 including `base`. The previous authors and maintainers of the core libraries slowly exited the community for various reasons, and due to lack of ability to find new maintainers, responsibility devolved to the CLC taking control. The CLC, however, did not grow along with it. CLC members viewed these packages as stable, and therefore not in need of consistent code-changes modulo a version bump here and there, or the odd update for new GHC features. ## CLC as of Today Today , we realize that the perception of a stable set of core libraries is not true to reality. In fact, this was realized about the time I joined in 2019, but it had not quite sunk in: our core libraries are in need of constant maintenance. In fact, many of the core libraries we do have are not stable because they are in a stable, performant and well-maintained state, but are stable because nothing has been done with them. It is a dire error that the two were confused. In many cases, we were the ones blocking the changes! This is not to say that each of the core libraries suffers, but many do, and this is a problem. For example, recently orders of magnitude changes in performance and usability came in the form of pull requests to `random` and `bytestring`, where before they were considered to be completely stable. In the case of `random`, a CLC member stood in the way of that progress. In the case of other libraries, progress stalled because the CLC was not equipped to maintain the libraries it was charged with stewarding, and new maintainers could not be found. However, this is not to heap blame on anyone in particular. The creeping expansion of our responsibilities on the CLC caused two major problems: 1. We had too many responsibilities, and scope kept creeping. What started out as `base` turned into `base` and stewarding core libraries. Stewarding the core libraries turned into maintaining the core libraries. Maintaining turned into architecting new feature changes etc. 2. Despite life generally being balanced with CLC duties, the last few years have also added the weight of a general malaise of stress induced by our respective sociopolitical and economic climates. As a result, despite being 8-strong on paper, the CLC has actually been operating with only 2.5 active people since 2019 (the .5 coming from 2 sporadically active CLC members). This is not enough to keep up with the general workload, nor enough to decide quorum. Behind the scenes, we've been feeling this pressure and working with it since the COVID-19 pandemic started, but at this point in time, we're looking to disband the current iteration of the CLC and work towards a new structure that will be more maintainable in the future. ## CLC in the Future Three weeks ago, I sent out [an email]( https://hackmd.io/rSBGz4bgRgq5w-tUH_m68w ) to the CLC asking for a role call, advertising the will to restructure. With some gentle prodding, we have 3 members who raised their hand (Chessai, myself, and gwils), and 1 who will help us rebuild and reassess their involvement pending the outcome (Cale Gibbard). The 4 of us will meet on Thursday of next week to discuss a restructuring of our responsibilities and what to do moving forward. I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. This will effectively be reasserting the CLC's original mission statement, with some better process for onboarding community-led contributions to `base`, and a clearer notion of what it means to maintain core libraries. Then, finding new maintainers for some of the core libraries will be the final hurdle for the new CLC. I think this is a very necessary change that is possibly 5 years too late, but c'est la vie. I'm happy that the CLC are amenable to this change, and I hope that we see alot of very fruitful discussion amongst the community on how best to structure in a way that meets your demands more effectively. I'm putting a time box on a finished process by mid to late September (give us a month+ to sort it out), and we'll be back and more effective than ever. Also, since the email sent out served as a means of figuring out which members were actively, we will be adding as many or more CLC members to help move things forward. Cheers, and I hope this gives enough detail for everyone. Emily

4 9

[RFC] Semantics of size hints in text package
by Andrew Lelechenko 19 Jul '21

19 Jul '21

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 <https://github.com/haskell/text/issues/356>. Best regards, Andrew

1 0

Question about withMVar
by Harendra Kumar 18 Jul '21

18 Jul '21

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

4 3

Proposal: make liftF a method of MonadFree
by David Feuer 17 Jul '21

17 Jul '21

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

3 4

[RFC] Support Unicode characters in instance Show String
by Kai Ma 11 Jul '21

11 Jul '21

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.ht… [2] https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html [3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79… [4] https://www.python.org/dev/peps/pep-0538/

10 25

Export Natural type from prelude
by Carter Schonwald 07 Jul '21

07 Jul '21

This seems long overdue and aside from some redundant import warnings likely low breakage risk Thoughts?

8 13

Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list?
by Andrew Lelechenko 07 Jul '21

07 Jul '21

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 <oleg.grenrus(a)iki.fi> > > 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

2 2

Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list?
by Oleg Grenrus 07 Jul '21

07 Jul '21

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

6 12