November 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

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

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

10 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 01 Jan '15

01 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

Discussion: Strict maps
by David Feuer 23 Dec '14

23 Dec '14

The containers package has Data.Map.Strict and Data.IntMap.Strict, offering functions for handling maps that are strict in the values stored. But these modules are lies, as comments in the source explain: -- API of this module is strict in the keys, but lazy in the values. -- If you need value-strict maps, use "Data.Map.Strict" instead. -- The 'Map' type itself is shared between the lazy and strict modules, -- meaning that the same 'Map' value can be passed to functions in -- both modules (although that is rarely needed). -- Be aware that the 'Functor', 'Traversable' and 'Data' instances -- are the same as for the "Data.Map.Lazy" module, so if they are used -- on strict maps, the resulting maps will be lazy. Yuck. This is not nice. Clearly, the current interfaces need to stay around for compatibility, but I think we should add some unbroken ones too. There are two and a half sane ways to do this: 1. Make strict types that just wrap the lazy ones in newtype wrappers. The benefits: a) They can reuse all the code from Data.Map.Strict or Data.IntMap.Strict, producing tiny little wrapper modules. b) They can support cheap strictToLazy and unsafeLazyToStrict operations (newtype unwrappers/wrappers). c) They support lazyToStrict operations with no significant new code (reusing the NFData code). 2. Make entirely separate strict types. The benefits: a) The code implementing them does not have to be careful to force everything as it goes in, so the strictness is maintained automatically; changes to the code don't need careful strictness auditing. b) Values only need to be forced on insertion, and GHC should be able to recognize that returned values will have been forced. This should speed things up when lookups are common and updates are rare. c) There may (I'm not sure) be more opportunities for GHC to unbox values when their types are known. 2.5. Do both of the above.

4 6

Proposal: relax type of asProxyTypeOf
by Daniel Wagner 07 Dec '14

07 Dec '14

In base, the new Data.Proxy module has this handy function: asProxyTypeOf :: a -> Proxy a -> a asProxyTypeOf = const This is nice for restricting the phantom type variable of a Proxy that you have lying around. This use could be generalized to other types with phantom type variables by making the type slightly more polymorphic: asProxyTypeOf :: a -> proxy a -> a Since phantom type variables are a very common pattern, this would make asProxyTypeOf more generally useful. Possible downside: it may be that somebody used asProxyTypeOf to restrict both the phantom type and the "Proxy" type, and that the more polymorphic type for asProxyTypeOf would cause that code to break. I find this pretty unlikely. Perhaps the folks behind the "tagged" package could mention whether this complaint ever came up when it made a similar generalization. ~d

2 1

Implement `calloc{,Bytes,Array,Array0}` allocators
by Oleksandr Petrov 02 Dec '14

02 Dec '14

Hi everyone, There is a proposal [1] (with implemented revision) to implement zero-initialising versions of malloc{,Bytes,Array,Array0} - Add calloc and callocBytes to Foreign.Marshal.Alloc. - Add callocArray and callocArray0 to Foreign.Marshal.Array. The benefit is that you can allocate required amount of memory and be certain that it will be cleared (set with zeroes) before you use it. Original discussion took a place in `fillBytes` [1] and was publicised on that mailing list [2]. Please share your thoughts. Thank you. [1] https://phabricator.haskell.org/D527 [2] https://phabricator.haskell.org/D461#11541 [3] https://www.haskell.org/pipermail/libraries/2014-November/024251.html -- alex p

6 6

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

01 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

process: Confusion about UseHandle handles being closed.
by Michael Snoyman 29 Nov '14

29 Nov '14

I originally opened this as a Github issue[1] about this, but due to lack of attention, Herbert recommended that I send it to the libraries list as well. Here's the issue description copied verbatim from Github: When working on a library, I was surprised to find that the `Handle`s that I passed in for `std_in`, `std_out` and `std_err` via `UseHandle` were automatically closed. This is not clear from the documentation, and- at least for the use case I was interested in- the opposite of what I needed. There are valid cases where we'd want the `Handle` to remain open after the process runs to completion. The function `createProcess_` in the `.Internals` module has the behavior I was looking for, and for my purpose, I can simply import from there. I'd like to propose two changes: 1. Add clear documentation to `createProcess` indicating that it will close the `Handle` automatically. 2. Add a new function to be exported from `System.Process` with the semantics of `createProcess_`. I'm open to bikeshedding on the name, but perhaps sticking with `createProcess_` makes the most sense. Note that I do *not* think we should change the existing semantics of `createProcess`: I think it's a large breaking change, and should be avoided. I'm happy to provide pull requests for both of these, I just wanted to check if there was objection before going ahead with it. Michael [1] https://github.com/haskell/process/issues/2

7 15

Why is there no Monoid instance for Either?
by Francesco Mazzoli 27 Nov '14

27 Nov '14

Hi, Lately, I found myself wanting to use the following Monoid instance: ```` instance (Monoid b) => Monoid (Either a b) where mempty = Right mempty Left e `mappend` _ = Left e _ `mappend` Left e = Left e Right x `mappend` Right y = Right (x `mappend` y) ```` It would seem quite justified to me, given the left-bias of Either elsewhere in base. Is there any particular reason why it shouldn't be defined? It would break the instance for Either in `semigroups`, which is ```` instance Semigroup (Either a b) where Left _ <> b = b a <> _ = a ```` But I think mine is more useful, and has the additional advantage of having `mappend` to behave very similar to the `mappend` for `Maybe`. Francesco

2 2