March 2021 - Libraries

Fwd: New Libraries Proposal process
by Carter Schonwald 01 Jul '21

01 Jul '21

Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. Merry Friday and be well -Carter ---------- Forwarded message --------- From: chessai <chessai1996(a)gmail.com> Date: Fri, Sep 11, 2020 at 10:02 PM Subject: Re: New Libraries Proposal process To: Carter Schonwald <carter.schonwald(a)gmail.com> This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately. > All libraries process needs to start on the libraries mailing list Not anymore. The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise. This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution. Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries. On Fri, Sep 11, 2020, 19:52 Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > Where was this discussed or proposed? All libraries process needs to start > on the libraries mailing list. And soemtimes Perhaps moving to clc list for > resolving tie breaking on controversial choices. > > The libraries archive goes back pretty far and email threading seems to > scale far better for participating in complex discussions than does githubs > comment collapsing on large discussions. > > On Fri, Sep 11, 2020 at 3:20 PM chessai <chessai1996(a)gmail.com> wrote: > >> All, >> >> >> There is a new Libraries Proposal process, inspired by the GHC Proposals >> process. >> >> Core Library APIs are critical. It's easy for a sensible proposal to >> languish or simply get dropped on the floor; and (in the other direction) a >> bit too easy for a proposal to make it into the core libraries without >> receiving the scrutiny it deserves. Most of the proposals that have been >> made on this mailing list, become lost to the archives. It's not easy for >> anyone to answer the question "what decisions has the CLC made recently?" >> without trawling a huge email archive. >> >> Of course, this is mostly for breaking changes or "big" introductions; we >> don't need a full proposal over something tiny, e.g. "a module from vector >> is missing a fold". That would be more appropriate on vector's issue >> tracker, and left to the maintainers to deal with. >> >> I encourage anyone interested to get started by reading the README at >> https://github.com/haskell-core/core-libraries-proposals. >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > >

10 13

New Libraries Proposal process
by chessai 01 Jul '21

01 Jul '21

All, There is a new Libraries Proposal process, inspired by the GHC Proposals process. Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with. I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.

5 7

template-haskell 2.17.0.0 not on Hackage
by Travis Cardwell 30 Mar '21

30 Mar '21

Hi, I noticed that template-haskell 2.17.0.0 has not been released to Hackage. One consequence of this is that the Hackage Dependency Monitor does not notify package maintainers of the major release. Releasing the new version on Hackage may prompt more package maintainers to update typed Template Haskell API code so that it works with GHC 9. Regards, Travis

6 6

Proposal: export more Data.Sequence internals
by David Feuer 17 Mar '21

17 Mar '21

I'd like containers to export more Data.Sequence internals, and to do so in a way that allows external users to rely on them. I propose the following: 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the finger trees used to represent sequences. These can also be used for other finger trees with measurements in the (Int, +) monoid. This would include various basic operations for cons, snoc, and splitting, with most names the same as for sequences. 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient mapping/traversing functions that rely on specific preconditions to maintain the internal fingertree annotation invariant. 3. Add a module, Data.Sequence.StableInternal, exporting the internal structure of sequences and also some internal functions that may be useful elsewhere (I'm particularly interested in the `splitMap` function and future variants thereof). Unlike the `.Internal` module, this module would be subject to the package version policy, and would therefore be more suitable for use by other packages. I am very open to suggestions for modifications to the module names. One option might be to put all the FingerTree.IntPlus stuff in the Data.Sequence.StableInternal hierarchy, if folks think it should be buried a bit. David

5 5

Proposal: add replay function to Control.Monad.Cont.Class
by Alexandre Esteves 14 Mar '21

14 Mar '21

I'd like to propose adding the following function (method?) to Control.Monad.Cont.Class, possibly with another name: replay :: MonadCont m => m (m a) replay = callCC $ pure . fix Using this in a do-notation block allows one to bind a name to the sub-block that starts immediately after. I reached for continuations to try to get this behavior for use with recursive flows without disrupting the reading of the main forward flow and found how to do it in https://jsdw.me/posts/haskell-cont-monad/ under the name "goto". While "goto" is as familiar as a name can be, I feel "replay" more accurately conveys, that you can only 'go back', by stating what actually is happening - that a sub-block we're currently evaluating is replayed from its beginning. As a motivating example, here's the same recursive IO flow written in 3 ways - one with replay, one with fix, and one with where clauses. {-# LANGUAGE LambdaCase #-} import Control.Monad.Cont.Class (MonadCont(callCC)) import Control.Monad.IO.Class (MonadIO, liftIO) import Control.Monad.Trans.Cont (evalContT) import Data.Function (fix) import Text.Read (readMaybe) replay :: MonadCont m => m (m a) replay = callCC $ pure . fix prompt :: MonadIO m => String -> m String prompt t = liftIO $ do putStrLn t putStr "> " getLine flowContT :: IO () flowContT = evalContT $ do liftIO $ putStrLn "Welcome to the totally not contrived game" numberPromptStep <- replay readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> liftIO $ putStrLn $ "You picked " <> show (n :: Int) exitPromptStep <- replay prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep flowFix :: IO () flowFix = do putStrLn "Welcome to the totally not contrived game" fix $ \numberPromptStep -> do readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> liftIO $ putStrLn $ "You picked " <> show (n :: Int) fix $ \exitPromptStep -> do prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep flowWhere :: IO () flowWhere = do putStrLn "Welcome to the totally not contrived game" numberPromptStep where numberPromptStep = do readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> do liftIO $ putStrLn $ "You picked " <> show (n :: Int) exitPromptStep exitPromptStep = do prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep

6 7