November 2014 - Libraries

PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds
by Sean Leather 25 Nov '14

25 Nov '14

Inspired by conversations recent [1] and not-so-recent [2] and by my own past wish for this, I propose adding the following function to base: toBoundedIntegral :: (Integral a, Integral b, Bounded b) => a -> Maybe b toBoundedIntegral x | y > toInteger (maxBound `asTypeOf` z) = Nothing | y < toInteger (minBound `asTypeOf` z) = Nothing | otherwise = Just $! z where y = toInteger x z = fromInteger y This includes rules to optimize for many cases where we know the bounds at compile time. See the gist for the full implementation: https://gist.github.com/spl/1986c9ff0b2416948957 I'm not particularly concerned with the precise location of this function. It could start out in GHC.Int if there's controversy. Otherwise, Data.Int would be an option to avoid polluting the Prelude. I chose the name to be descriptive of the result type, which is the more constrained type. The function that I started from [2] was called fromIntegralSafe, but I think “safe” is too ambiguous here. I did not find “toBoundedIntegral” in any package on Hackage. I welcome review of the implementation and rules. Discussion period: ~10 days if there is a strong desire to get it in GHC 7.10. (I would certainly like to see it get in.) Otherwise, I can make a package, and we can revisit the issue at another time. Regards, Sean [1] Evan Laforge: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/113600/focus=113648 [2] Stephen Paul Weber: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/102613/focus=64686

4 16

Final bikeshedding call: Fixing Control.Exception.bracket
by Merijn Verstraaten 23 Nov '14

23 Nov '14

Ola! In September Eyal Lotem raised the issue of bracket's cleanup handler not being uninterruptible [1]. This is a final bikeshedding email before I submit a patch. The problem, summarised: Blocking cleanup actions can be interrupted, causing cleanup not to happen and potentially leaking resources. Main objection to making the cleanup handler uninterruptible: Could cause deadlock if the code relies on async exceptions to interrupt a blocked thread. I count only two objections in the previous thread, 1 on the grounds that "deadlocks are NOT unlikely" and 1 that is conditioned on "I don't believe this is a problem". The rest seems either +1, or at least agrees that the status quo is *worse* than the proposed solution. My counter to these objections is: 1) No one has yet shown me any code that relies on the cleanup handler being interruptible 2) There are plenty of examples of current code being broken, for example every single 'bracket' using file handles is broken due to handle operations using a potentially blocking MVar operation internally, potentially leaking file descriptors/handles. 3) Even GHC-HQ can't use bracket correctly (see Simon's emails) Potential solution #1: Leave bracket as-is, add bracketUninterruptible with an uninterruptible cleanup handler. Potential solution #2: Change bracket to use uninterruptible cleanup handler, add bracketInterruptible for interruptible cleanups. Trade-offs: Solution 1 won't change the semantics of any existing code, however this also means that any currently broken uses of bracket will remain broken, possibly indefinitely. Solution 2 will change the semantics of bracket, which means any currently broken uses of bracket will be fixed, at the cost of creating potential deadlocks in code that relies on the interruptibility of cleanup. I will argue that solution #2 is preferable, since I have yet to see any code that uses the interruptibility of the cleanup handler. Whereas there's many broken assumption assuming the cleanup handler is not interruptible. Secondly, it is easier to detect deadlocks caused by this problem than it is to detect resource leaks which only happen in unlucky timings of async exceptions. Especially since any deadlock caused by the change can be fixed by replacing bracket with bracketInterruptible. [1] - https://www.haskell.org/pipermail/libraries/2014-September/023675.html Cheers, Merijn

17 88

Proposal: Add 'fillBytes' to Foreign.Marshal.Utils
by Alex Petrov 23 Nov '14

23 Nov '14

Hi everyone, Currently the memory allocated with (Foreign.Marshal.Alloc) malloc may potentially be dirty. In C this problem is usually solved by using memset. This would be extremely useful for FFI / C interop, when a data structure is allocated within Haskell code. With memset, you can do something like customMem <- malloc _ <- memset (castPtr customMem) 0 #{size custom_t} This will fill a block of allocated memory with zeroes. For example, I've been working on FFI bindings for collectd, and when I was allocating memory, previously used within the process, it was dirty, so my CString contained a value of "custom name7e0700490, test_plugin_LTX_module_register): symbol nd" Instead of just "custom name" After using memset and filling everything with zeroes, problem never appeared again. This can be implemented in user applications, too, although it would be really nice to have it by default. This is a common practice in C world, and this function is not only useful for cases when the memory was just allocated from Haskell process, but also when one receives a dirty memory buffer from C code. The patch for proposal was implemented and is available on Phabricator: https://phabricator.haskell.org/D465 Please share your thoughts. Alex https://twitter.com/ifesdjeen http://clojurewerkz.org/

5 5

PROPOSAL: Add displayException to Exception typeclass
by Michael Snoyman 21 Nov '14

21 Nov '14

I started a discussion a few weeks back on some theoretical changes to how exceptions are displayed. That discussion covered a lot of different ground. I'd now like to formally propose the original change I mentioned in that thread: 1. Add a new method to the Exception typeclass: -- | Render this exception value in a human-friendly manner. Default implementation: @show@. displayException :: e -> String displayException = show 2. Modify GHC's default exception handler to use `displayException` instead of `show`. This change will, on its own, cause no breakage[1] and, without further action, will have no change in program behavior. It does, however, allow users to begin distinguishing between how their exceptions should be `show`n versus how they should be displayed to an end user. Note that I am *not* proposing at this time any other changes discussed in the previous thread. If someone wants to propose removing Show superclasses, adding a Read superclass, providing a typeRepStack method[2], or something else, please propose it separately. Discussion period: two weeks. Michael [1] Besides introducing a new, possibly clashing identifier name. [2] That one actually seems like a very good idea to me.

12 34

PROPOSAL: Add 'Natural' type to base:Data.Word
by Herbert Valerio Riedel 18 Nov '14

18 Nov '14

Hello CLC et al., I hereby suggest to add a type for encoding term-level naturals data Natural = <opaque/hidden> deriving (...the usual standard classes...) to `base:Data.Word` module Motivation ========== - GHC 7.10 is planned to ship with integer-gmp2[2] as its default `Integer` lib, whose low-level primitives are based on *unsigned* BigNums. And 'Natural' type for integer-gmp2 can be implemented directly w/o the overhead of wrapping an `Integer` via data Natural = NatS# Word# | NatJ# !PrimBigNat# as well as having a twice as large domain handled via the small-word constructor and thus avoiding FFI calls into GMP. - GHC/`base` already provides type-level naturals, but no term-level naturals - Remove the asymmetry of having an unbounded signed `Integer` but no unbounded /unsigned/ integral type. Also, `Data.Word` has been carrying the following note[1] for some time now: > It would be very natural to add a type Natural providing an > unbounded size unsigned integer, just as Integer provides unbounded > size signed integers. We do not do that yet since there is no > demand for it. Discussion period: ~10 days (GHC 7.10 RC freeze is scheduled for Nov 21st) Cheers, hvr [1]: http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Word.html#g:3 [2]: https://phabricator.haskell.org/D82 https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2

24 38

Why the presence/absence of the HsColour binary forces to recompile the QuickCheck library?
by Andrés Sicard-Ramírez 18 Nov '14

18 Nov '14

Hi, (The Cabal home page https://www.haskell.org/cabal/ says I can send questions about Cabal to this mailing list). My question is http://stackoverflow.com/questions/26785036/why-the-presence-absence-of-the… . Thanks, -- Andrés

1 0

Proposal: Make amap an IArray method
by David Feuer 14 Nov '14

14 Nov '14

I realized what I wrote about amap earlier was utterly boneheaded, because it has the wrong type for fmap. The only way to accomplish my goal is to make Data.Array.IArray.amap a method of the IArray class. This will allow IArray instances to offer optimized versions and things like amap/coerce rules. The current implementation of amap can become the default one.

2 4

Discussion: expand documentation of amap for IArray
by David Feuer 14 Nov '14

14 Nov '14

The current documentation for Data.Array.IArray.amap says what it does, but doesn't say anything about how it should (and shouldn't!) be used. Specifically, it does not implement amap/amap or amap/coerce rules, and it probably cannot do so safely if the IArray instance does not satisfy the appropriate lens-like laws. Thus the most appropriate way to use this function is probably to implement the Functor instance for an IArray type, using type-specific RULES. It's probably *not* such a hot idea to use this amap directly. I don't know if all that should be crammed, with explanation, into the Haddocks or if there's a better way to handle it. David

1 0

Monoid instance for IO
by Gabriel Gonzalez 14 Nov '14

14 Nov '14

I would like to add the following `Monoid` instance for `IO` to `Data.Monoid`: ``` instance Monoid a => Monoid (IO a) where mempty = pure mempty mappend = liftA2 mappend ``` I describe the benefit of this particular instance in this blog post: http://www.haskellforall.com/2014/07/equational-reasoning-at-scale.html ... and Conal Elliot describes the general trick of recursively lifting `Monoid` instances in his type class morphisms paper: http://conal.net/papers/type-class-morphisms/type-class-morphisms-long.pdf The primary benefit of the `Monoid` instance is that it chains well with other `Monoid` instances in `base` to create derived `Monoid` instances. The following types are examples of useful derived `Monoid` instances: ``` IO () -- Because `()` is a `Monoid` a -> IO () -- Because `a -> r` is a `Monoid` if `r` is a `Monoid` IO (a -> IO ()) -- This comment explains the utility of this instance: http://www.reddit.com/r/haskell/comments/22bn1m/monads_lifting_join_and_sid… ``` Here are other alternatives that I considered: **Alternative A)** Define a newtype for the `Monoid` instance, either specialized to `IO`: ``` newtype IOMonoid a = IOMonoid { getIOMonoid :: IO a } deriving (Functor, Applicative, Monad) instance Monoid a => Monoid (IOMonoid a) where mempty = pure mempty mappend = liftA2 mappend ``` ... or generalized to all applicatives: ``` newtype LiftMonoid f a = LiftMonoid ( getLiftMonoid :: f a } instance (Applicative f, Monoid a) => Monoid (LiftMonoid f a) where ... ``` I prefer not to use a newtype because the principle benefit of a `Monoid` instance for `IO` is for the derived instances. Using the example `IO (a -> IO ())` type, suppose that I had two values of that type which I wanted to mappend: ``` m :: IO (a -> IO ()) n :: IO (a -> IO ()) ``` Using newtypes (either one), I'd have to write: ``` getNewtype (Newtype (fmap (fmap Newtype) m) <> Newtype (fmap (fmap Newtype) n)) ``` ... instead of just: ``` m <> n ``` **Alternative B)** Provide a different `Monoid` instance for `IO`, such as one that uses concurrency There are two issues with this approach: 1. There is not a well-defined semantics for non-`STM` concurrency that we could use to prove the `Monoid` laws 2. Even if there were a well-defined semantics, it would be better suited as an `Alternative` instance instead of a `Monoid` instance To clarify the latter point, Peaker convinced me [[ http://www.reddit.com/r/haskell/comments/2guo44/what_is_wrong_with_the_mono… | here ]] that for certain `Applicative`s it's worth distinguishing the behavior of the `Alternative` instance from the behavior of the `Monoid` instance. The `Monoid` instance can recursively delegate to the `Monoid` instance of the `Applicative`'s type parameter, whereas the `Alternative` instance cannot. I also created a task on phabricator here since I'm used to the Github style of discussing issues on the repository issue tracker: https://phabricator.haskell.org/T55?workflow=create

7 6

Proposal: Make GHC.Arr.listArray slightly stricter to allow fusion
by David Feuer 14 Nov '14

14 Nov '14

Currently, GHC.Arr.listArray is pretty lazy: listArray (1,3) $ [1,2,3] ++ undefined will work perfectly fine. This is actually lazier than the current array: array (1,3) $ [(1,1), (2,2), (3,3)] ++ undefined = undefined Unfortunately, I don't think it's possible to make listArray fuse with a list producer while preserving quite that level of laziness. If we're willing to be slightly stricter, however, I think everything works. Specifically, I propose that we allow listArray (length xs) (xs ++ _|_) = _|_ The resulting listArray code is below. {-# INLINE mylistArray #-} listArray :: Ix i => (i,i) -> [e] -> Array i e listArray (l,u) es = runST (ST $ \s1# -> case safeRangeSize (l,u) of { n@(I# n#) -> case newArray# n# arrEleBottom s1# of { (# s2#, marr# #) -> let fillFromList y r i# s3# | isTrue# (i# ==# n#) = s3# | otherwise = case writeArray# marr# i# y s3# of s4# -> r (i# +# 1#) s4# in case foldr fillFromList (\_ s# -> s#) es 0# s2# of s5# -> done l u n marr# s5# }})

3 4