September 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 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

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

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

29 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

Proposal: Add a strictly accumulating scanl' to Data.List
by David Feuer 28 Oct '14

28 Oct '14

Joachim Breitner wrote, in https://ghc.haskell.org/trac/ghc/ticket/9345#comment:6, a strictly accumulating version of scanl, to be named scanl'. I was initially concerned about its safety for fusion, but am now convinced of its correctness and believe it should be added to Data.List. scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f a bs = build $ \c n -> a `seq` a `c` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `c` g b'))) (\b -> b `seq` n) bs a

3 3

Proposal: end lazy IO results with errors/exceptions
by David Feuer 10 Oct '14

10 Oct '14

Currently, withFile "foo" hGetContents >>= putStrLn prints out an empty line, the better to confuse newbies. I propose modifying the lazyRead function in GHC.IO.Handle.Text that currently reads lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, "") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) to something like lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, error "Forcing the result of a lazy read led to an attempt to read from a closed handle.") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) Ideally that error should instead be something to throw an imprecise exception, but I don't know how to use those yet. I can't personally see a way for this to break sane, working code, but the folks on #ghc thought it should be discussed and debated on list. David Feuer

10 12

Removing MonadFail from Monad
by David Luposchainsky 03 Oct '14

03 Oct '14

Hey everyone, I feel like there are a couple of elephants in the room that are sort of important but nobody really addresses them directly. One of them was what became the AMP, and `fail` is another one. I resurrected and refurbished this proposal from a 6 month old Gist because there seemed to be some interest/talk going on in the form of side remarks in other discussions here. The sun shines, let's make some hay! The proposal text can be found at the end of this text (for the mailman archives), or in pretty HTML here: https://github.com/quchen/articles/blob/master/monad_fail.md Although this will technically a language-level change, the impact will mainly be a library and fail-safety detail. For this reason I think this mailing list is more suitable than other more specialized lists. Greetings, David/quchen PS: I would have chosen Fail Removal Proposal so we have a new buzzword, but unfortunately it does not abbreviate well. Call it the "fail of Haskell issue"? ;-) Removing `fail` from `Monad` ============================ The problem ----------- Currently, the `<-` symbol is desugared as follows: ```haskell do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` The problem with this is that `fail` cannot be sensibly implemented for many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to `error`, i.e. the monad has a built-in crash. `MonadFail` class ----------------- To fix this, introduce a new typeclass: ```haskell class Monad m => MonadFail m where fail :: String -> m a ``` Desugaring is then changed to the following: ```haskell -- Explicitly irrefutable pattern: do not add MonadFail constraint do ~pat <- computation >>> let f pat = more more >>> in computation >>= f -- Only one data constructor: do not add MonadFail constraint do (Only x) <- computation >>> let f (Only x) = more more >>> in computation >>= f -- Otherwise: add MonadFail constraint do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` Discussion ---------- - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class should be created. A parser might fail with an error message involving positional information, and for STM failure is undefined although it is `MonadPlus`. - The case of one data constructor should emit a warning if the data type is defined via `data`: adding another data constructor can make patterns in unrelated modules refutable. - Some monads use the pattern matching to force evaluation of the binding, for example lazy/strict `StateT`. I'm not sure what exactly the consequences of the above are here; I suspect a strictness annotation or `(>>=)` instead of `do` notation might be sufficient. - Getting the change to work should be boring but painless: all Monad instance declarations involving `fail` will break because the function is removed, and many monadic computations have to be annotated using `~` because they were written under the assumption that `fail` is never called. In both these cases compilation errors/warnings carry sufficient information to fix the source code easily. - Backwards compatibility with many old modules will be broken; I don't see a way around this. Other things to consider ------------------------ - Rename `fail`? It's quite a generic name that would be nice to have in APIs. `failM`? `mfail`? - Remove the `String` argument? (May hurt error reporting on pattern mismatch ..?) - How sensitive would existing code be to subtle changes in the strictness behaviour of `do` notation pattern matching? Applying the change ------------------- Like the AMP, 1. Implement ad-hoc warnings that code will receive a `MonadFail` constraint in a future version. "Either make the patterns irrefutable, or keep in mind that the next compiler version will require a `MonadFail` instance". Since `MonadFail` does not clash with an existing name, it could be introduced to `Control.Monad` right away. 2. Do the switch.

9 11

Re: Proposal: Use uninterruptibleMask for cleanup actions in Control.Exception
by Eyal Lotem 02 Oct '14

02 Oct '14

Hey Simon, thanks for the reply! On Fri, Sep 5, 2014 at 6:39 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: > Eyal, thanks for bringing up this issue. It's been at the back of my mind > for a while, but I've never really thought through the issues and > consequences of changes. So this is a good opportunity to do that. You > point out (in another email in the thread) that: > > A) Cases that were not interruptible will remain the same. > B) Cases that were interruptible were bugs and will be fixed. > > However, > > C) Some bugs will turn into deadlocks (unkillable threads) > > Being able to recover from bugs is an important property in large > long-running systems. So this is a serious problem. Hence why I always > treat uninterruptibleMask with the deepest suspicion. > Recovering from various kinds of failures makes a lot of sense. But how can you recover from arbitrary invariants of the program being broken? For example, if you use a bracket on some semaphore monitoring a global resource. How do you recover from a bug of leaking semaphore tokens? Recovering from crashes of whole processes whose internal state can be recovered to a fresh, usable state, is a great feature. Recovering from thread crashes that share arbitrary mutable state with other threads is not practical, I believe. > Let's consider the case where we have an interruptible operation in the > handler, and divide it into two (er three): > > 1. it blocks for a short bounded amount of time. > 2. It blocks for a long time > 3. It blocks indefinitely > > These are all buggy, but in different ways. Only (1) is fixed by adding > uninterruptibleMask. (2) is "fixed", but in exchange for an unresponsive > thread - also undesirable. (3) was a bug in the application code, and > turns into a deadlock with uninterruptibleMask, which is undesirable. > I think that (1) is by far the most common and is very prevalent. I think 0-time interruptible (that can block but almost never do) operations are the most common cleanup handlers. For (2) and (3), we need to choose the lesser evil: A) Deadlocks and/or unresponsiveness B) Arbitrary invariants being broken and leaks In my experience, A tends to manifest exactly where the bug is, and is therefore easy to debug and mostly a "performance bug" . B tends to manifest as difficult to explain behavior elsewhere from where the bug actually is, and is usually a "correctness bug", which is almost always worse. Therefore, I think A is a far far lesser evil than B, when (2) and (3) are involved. I'd like to reemphasize that this change will almost always fix the problem completely since the most common case is (1), and in rare cases, it will convert B to A, which is also, IMO, very desirable. > This is as far as I've got thinking through the issues so far. I wonder > to what extent the programmer can and should mitigate these cases, and how > much we can help them. I don't want unkillable threads, even when caused > by buggy code. > Cheers, > Simon > > > On 04/09/2014 16:46, Roman Cheplyaka wrote: > >> I find your arguments quite convincing. Count that as +1 from me. >> >> Roman >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> -- Eyal

3 3