October 2014 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 11 Oct '15

11 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

Proposal: improve the Data.Tree API
by João Cristóvão 02 Jan '15

02 Jan '15

Hello, The Data.Tree API seems rather poor. Some research on hackage shows some additional functions being defined in very unrelated packages: http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies… http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.ht… I propose the addition of the following functions, that seem rather straigh forward to me: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a The 'Tree' is appended in the name, to distinguish from the Foldable instances, that return the value, and not a sub-tree. Additionally, the following two functions might also be useful (even if the implementation is very simple in the second case): -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | Length of the tree length :: Tree a -> Int There are probably more useful functions to add, so suggestions are welcomed. Previous discussion: https://github.com/haskell/containers/issues/39#issuecomment-35799628 Discussion period: 2 weeks Cheers, João

12 35

Proposal unix. Change to `IO (Maybe String)`: getLoginName, getUserEntry* and getGroupEntry*
by Thomas Miedema 02 Dec '14

02 Dec '14

In the unix package, in System.Posix.User, we have the following functions [1]: * getLoginName (getlogin) * getUserEntryForID (getpwuid_r) * getGroupEntryForID (getgrgid_r) * getUserEntryForName (getpwnam_r) * getGroupEntryForName (getgrnam_r) They have signature `IO String`, and use `throwErrnoIfNull` to call the c functions listed in parenthesis. ## Proposal Change the signature of the functions listed above to `IO (Maybe String)`. The new semantics would be: * If the c function returns a NULL pointer with errno set to ENOENT, meaning the given user or group could not be found, the result is Nothing. * If another error occured, an error is thrown (no change). * Otherwise the result is Just "result". ## Motivation At least `getlogin` and `getgrgid` are unreliable on Linux. It is possible for them to return NULL pointers [2] even when the user is logged in and has an associated user entry in /etc/passwd and group entry in /etc/group. Examples: * when `getLoginName` is called using a terminal emulator that doesn't write login records to /var/run/utmp, or inside screen/tmux, `getlogin` tends to return NULL pointers [3]. * `getGroupEntryForID` can throw a NULL pointer exception inside chroots or other environments where the information in /etc/groups is not to be considered reliable [4]. Since we can, let's give the above Haskell functions a type safe(r) api. If the proposal gets rejected, I will just add a warning message to the docstrings of the functions in question and permanently disable their tests from the unix testsuite, since this is currently causing problems [5,6]. Discussion period: 2 weeks. ## Links [1] https://github.com/haskell/unix/blob/master/System/Posix/User.hsc [2] http://linux.die.net/man/3/getlogin [3] https://github.com/haskell/unix/blob/cad1ef27bb0a51bc68ebadb1297de1ae05bee9… [4] https://ghc.haskell.org/trac/ghc/ticket/8293 [5] http://www.haskell.org/pipermail/ghc-devs/2014-September/006420.html [6] https://ghc.haskell.org/trac/ghc/ticket/1487#comment:23 ## Details * Another function in the same module that needs to change is `getEffectiveUserName`, because it calls the function `getUserEntryForID` mentioned before. * The following functions don't need to change, since they return the empty list if no entries are found: - getGroups (getgroups) - getAllGroupEntries (getgrent) - getAllUserEntries (getpwent) * The rest of the functions in the module don't need to change either, since they are not expected to return NULL pointers, according to their respective man pages: - getRealUserID (getuid) - getRealGroupID (getgid) - getEffectiveUserID (geteuid) - getEffectiveGroupID (getegid)

5 4

Proposal: Add isSubsequenceOf to Data.List
by Niklas Hambüchen 04 Nov '14

04 Nov '14

Data.List has `subsequences`, calculating all subsequences of a list, but it doesn't provide a function to check whether a list is a subsequence of another list. `isSubsequenceOf` would go into the "Predicates" section (http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-List.html#g:12) which already contains: * isPrefixOf (dual of inits) * isSuffixOf (dual of tails) * isInfixOf With this proposal, we would add * isSubsequenceOf (dual of subsequences) Suggested implementation: -- | `isSubsequenceOf a b`: Checks if a is a subsequence of b. isSubsequenceOf :: (Eq a) => [a] -> [a] -> Bool isSubsequenceOf [] _ = True isSubsequenceOf _ [] = False isSubsequenceOf a@(x:a') (y:b) | x == y = isSubsequenceOf a' b | otherwise = isSubsequenceOf a b Niklas

4 4

Proposal: Make default impls for foldl1 and foldr1 lazier
by David Feuer 02 Nov '14

02 Nov '14

We currently have (in Data.Foldable) foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) and something similar for foldl1. This is strict in the entire spine, unlike the list version, because it has to get all the way to the end of the list before it starts laying down Justs. I propose we change this to the obvious: foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x r = Just $ case r of Nothing -> x Just y -> f x y Since GHC 7.10.1 is fast approaching, I doubt we have the usual two weeks to discuss this, so please speak up as soon as you can if you have concerns.

5 4

Proposal: Add Alternative adapter to Data.Monoid
by David Feuer 01 Nov '14

01 Nov '14

I found myself needing this type in my current overhaul of Data.Foldable, but it seems to be generally useful: newtype Alt f a = Alt { getAlt :: f a } deriving (Eq,Ord,Show,Read,Typeable,Data,Generic,Num,Real, Floating, Fractional, RealFrac, RealFloat, Integral, Enum, Bounded,Ix,Functor,Foldable,Traversable,Applicative, Alternative,Monad,MonadPlus,MonadFix, IsString, IsList) -- The laundry list of derived instances is as recommended by Edward Kmett, who would probably want more added if someone can think of more. Some of them would, of course, need to be derived in other modules. The key instance is this: instance Alternative t => Monoid (Alt t a) where mempty = Alt empty (Alt m) `mappend` (Alt n) = Alt (m <|> n)

6 9

Discussion: adding displayException to Exception class
by Michael Snoyman 31 Oct '14

31 Oct '14

I don't want to make a format proposal yet, just open up discussion on an issue, and see how others feel about it. As I recently commented on this list[1], the Show typeclass is overloaded with multiple meanings (serialization, debug info, and user-friendly data display). The general consensus seems to be that the official semantics for Show should be for serialization (as paired up with Read). However, there's at least one use case in base which explicitly uses Show for non-serialization purposes: the Exception class. All instances of Exception are required to have an instance of Show, but there's no way to actually serialize exceptions generally[2]. So by construction and by practice, the Show instance for Exception is used exclusively for the latter two categories I mentioned (debug info and user-friendly data display). As a result of that, it's quite common[3] to define a Show instance for exception types that is *not* serializable, but rather user friendly. This however seems to contradict what is accepted as good practice in general. I have a possible solution that I'd like to propose as a strawman: add a new method to the Exception typeclass: displayException :: e -> String displayException = show The name is up for debate, but I chose `display` since it seems to already be used elsewhere for user-friendly output. Other possible choices are showException or prettyException. The default implementation will reuse the Show instance, so no user code will be broken by this[4]. In the short term, the only other change I'd recommend is that the default exception handler use `displayException` instead of `show` for printing uncaught exceptions. Longer term, after deprecation cycles, we could consider removing the Show superclass from Exception. Again, this isn't a real proposal (yet), I'm more interested now in what people think about such a change. Michael [1] http://www.haskell.org/pipermail/libraries/2014-October/023957.html [2] Both due to how extensible exceptions work, and due to the lack of a Read superclass. [3] This discussion started when Chris Done and I were working with the tar package, which defines custom renderings for FormatError. I've implemented this same technique in some of my libraries, and I'm sure there are many other examples on Hackage. [4] Barring the standard issue of new identifiers clashing with identifiers defined locally.

17 34

Proposal: remove versionTags from Data.Version
by Thomas Miedema 30 Oct '14

30 Oct '14

Version in Data.Version from base is defined as: data Version = Version { versionBranch :: [Int], versionTags :: [String] } instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 ## Proposal Remove the `versionTags` field from this type. ## Motivation * The Eq and Ord instances of Version don't agree whether two versions with different versionTags are equal or not [1]: > a = Version [1] ["a"] > b = Version [1] ["b"] > compare a b EQ > a == b False * The Package versioning policy does not include version tags [2]. * Cabal no longer supports package version tags [3,4]. Discussion period: 2 weeks. Note: this is not a proposal to ignore trailing zeros when comparing versions. Neither is this is a proposal to change the Eq instance for Version to only consider the versionBranch field. This is a proposal to remove versionTags altogether. [1] https://ghc.haskell.org/trac/ghc/ticket/2496 [2] http://www.haskell.org/haskellwiki/Package_versioning_policy [3] https://github.com/haskell/cabal/issues/890 [4] http://www.haskell.org/cabal/users-guide/developing-packages.html#package-n…

4 5

Proposal: make nubBy obey the 98 report semantics
by Thomas Miedema 29 Oct '14

29 Oct '14

The implementation of nubBy in Data.List is as follows, where USE_REPORT_PRELUDE refers to [1]: #ifdef USE_REPORT_PRELUDE nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) #else nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a -> a -> Bool) -> a -> [a] -> Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs #endif That comment is actually not correct [2], and the report version and the base version don't have the same semantics when used on asymmetric relations: MyReportPrelude> nubBy (<) [1] [1] Data.List> nubBy (<) [1,2] [1,2] ## Proposal Make nubBy and nub obey the report semantics by swapping the arguments to `eq` in elem_by, and defining nub as nubBy (==). This is the 'still easy' variant from [3]. ## Motivation The Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. See [4,5] for user bug reports. Discussion period: 2 weeks Code review: https://phabricator.haskell.org/D238 [1] https://www.haskell.org/onlinereport/list.html#sect17.6 [2] https://ghc.haskell.org/trac/ghc/ticket/2528 [3] https://ghc.haskell.org/trac/ghc/ticket/7913#comment:3 [4] https://ghc.haskell.org/trac/ghc/ticket/3280 [5] https://ghc.haskell.org/trac/ghc/ticket/7913

4 4