- Libraries - Haskell.org

Typo in Data.Either
by roconnor＠theorem.ca 08 Oct '18

08 Oct '18

The Haddocks for the Applicative instance for (Either e) says since 3.0, but AFAICT it should be since 4.3.0.0. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

2 1

MonadFailProposal - missing instances in bootlibs
by lennart spitzner 04 Oct '18

04 Oct '18

Hi, While the impact seems low, some relatively trivial MonadFail instances seem to be missing still, including: Option, First, Last, Proxy, WrappedMonad. Also the non-base containers:Seq. These were not specifically discussed either [1]. Thoughts? Any other things that are still overlooked? -- lennart [1] https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Discussion

3 2

Proposal: Add HasCallStack to the partial functions in base
by Daniel Cartwright 28 Sep '18

28 Sep '18

I propose to add `HasCallStack` to all partial functions in base, e.g. `fromJust`, `fromRight`, `fromLeft`, etc. Relevant discussion here: https://ghc.haskell.org/trac/ghc/ticket/15559

4 4

Touching unlifted values
by Andrew Martin 21 Sep '18

21 Sep '18

The touch# primitive accepts a levity-polymorphic argument. I am wondering if there is ever any difference between using it on a lifted value and an unlifted value. Consider the following: module Lifted where import Control.Monad.ST (runST) import Control.Monad.Primitive (touch) import Data.Int (Int64) import Data.Primitive (newPinnedByteArray,mutableByteArrayContents,readOffAddr,writeOffAddr) computation :: Int64 computation = runST $ do arr <- newPinnedByteArray 8 let addr = mutableByteArrayContents arr writeOffAddr addr 0 (42 :: Int64) i <- readOffAddr addr 0 touch arr return i Calling touch on the mutable byte array is necessary to make sure that the memory that the Addr points doesn't get GCed while we are writing and reading to and from it. Here is the relevant GHC core (compiled with -O2): -- RHS size: {terms: 32, types: 67, coercions: 19, joins: 0/1} computation1 computation1 = \ s1_a24R -> case newPinnedByteArray# 8# (s1_a24R `cast` <Co:4>) of { (# ipv_a246, ipv1_a247 #) -> let { addr_s273 addr_s273 = byteArrayContents# (ipv1_a247 `cast` <Co:9>) } in case writeInt64OffAddr# addr_s273 0# 42# ipv_a246 of s'#_a24p { __DEFAULT -> case readInt64OffAddr# addr_s273 0# s'#_a24p of { (# ipv2_a267, ipv3_a268 #) -> case touch# ((MutableByteArray ipv1_a247) `cast` <Co:3>) (ipv2_a267 `cast` <Co:3>) of s'_a24K { __DEFAULT -> (# s'_a24K, I64# ipv3_a268 #) } } } } -- RHS size: {terms: 5, types: 30, coercions: 0, joins: 0/0} computation computation = case runRW# computation1 of { (# ipv_a239, ipv1_a23a #) -> ipv1_a23a } Instead, what if we touched the underlying unlifted MutableByteArray#? Here is the code for doing this: {-# language MagicHash #-} {-# language UnboxedTuples #-} module Unlifted ( computation ) where import System.IO.Unsafe (unsafeDupablePerformIO) import Control.Monad.Primitive (unsafePrimToPrim,primitive,PrimState,PrimMonad) import Data.Int (Int64) import Data.Primitive (MutableByteArray(..),newPinnedByteArray,mutableByteArrayContents,readOffAddr,writeOffAddr) import GHC.Exts (touch#,MutableByteArray#) computation :: Int64 computation = unsafeDupablePerformIO $ do arr@(MutableByteArray arr#) <- newPinnedByteArray 8 let addr = mutableByteArrayContents arr writeOffAddr addr 0 (42 :: Int64) i <- readOffAddr addr 0 touchUnlifted arr# return i touchUnlifted :: PrimMonad m => MutableByteArray# (PrimState m) -> m () touchUnlifted x = unsafePrimToPrim $ (primitive (\s -> case touch# x s of { s' -> (# s', () #) }) :: IO ()) GHC generates the following core for this module (again, omitting irrelevant parts): computation1 computation1 = \ s_a49h -> case newPinnedByteArray# 8# (s_a49h `cast` <Co:3>) of { (# ipv_a48a, ipv1_a48b #) -> let { addr_s4aY addr_s4aY = byteArrayContents# (ipv1_a48b `cast` <Co:8>) } in case writeInt64OffAddr# addr_s4aY 0# 42# ipv_a48a of s'#_a48A { __DEFAULT -> case readInt64OffAddr# addr_s4aY 0# s'#_a48A of { (# ipv2_a4aq, ipv3_a4ar #) -> case touch# ipv1_a48b (ipv2_a4aq `cast` <Co:2>) of s'_a2xn { __DEFAULT -> (# s'_a2xn, I64# ipv3_a4ar #) } } } } -- RHS size: {terms: 5, types: 30, coercions: 0, joins: 0/0} computation computation = case runRW# computation1 of { (# ipv_a47X, ipv1_a47Y #) -> ipv1_a47Y } I feel confident that both of these are semantically equivalent. Both uses of touch# should keep the MutableByteArray# alive until we are done using the pointer we extracted from it. What I'm less sure about is whether or not the first one actually does an alloctation for the MutableByteArray data constructor when it calls touch. Is this eliminated in some other stage of compilation? -- -Andrew Thaddeus Martin

2 1

Fwd: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed`
by andrew.lelechenko＠gmail.com 19 Sep '18

19 Sep '18

(Alexandre asked me to forward the email below on his behalf, because he is experiencing technical difficulties with this mail list. — Andrew) Greetings CLC; I'm writing this email to propose a change to `Data.Fixed`. Full credit for this idea goes to Bhavik Mehta (@b-mehta on GitHub), who implemented it in this PR for `exact-pi`. In `Data.Fixed` there are several `E`-prefixed datatypes used to represent a certain number of digits of precision in fixed-precision arithmetic. For example, `E1` has 1 decimal place, `E12` has 12. Each of them, `E{0,1,2,3,6,9,12}` is hardcoded. If more precision types are to be provided, they have to be hardcoded as well, and all of these types resemble each other. I think there is room for improvement here. Instead of having ``` data E0 instance HasResolution E0 where resolution _ = 1 ``` and repeating it as many times as there are `E` datatypes, I propose to add the following type: ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits (Nat, KnownNat, natVal) data E (n :: Nat) ``` and then do ``` instance KnownNat n => HasResolution (E n) where resolution _ = 10^natVal (undefined :: E n) ``` just once, replacing `data E0` with `type E0 = E 0` (and the same for the rest of them) to continue reexporting these types. `E` should also be exported. I have created a Trac feature request ticket with the same contents as this email, and made a PR to GHC’s repository on GitHub. To finalize, there are a few topics I’d like to raise regarding this change. 1. Does the community find this change beneficial in general? 2. Does the community approve of using DataKinds in a mundane section of the base package? 3. Does everyone accept a small breaking change of E0, E1, etc. from a data type to a type synonym? Or should we go the conservative way and just add E without refactoring E0, E1, etc.? Regards, Alexandre

4 3

Fwd: Add fixity for (==) and (/=)
by Dannyu NDos 18 Sep '18

18 Sep '18

---------- Forwarded message --------- From: Dannyu NDos <ndospark320(a)gmail.com> Date: 2018년 9월 17일 (월) 오후 6:18 Subject: Re: Add fixity for (==) and (/=) To: <david.feuer(a)gmail.com> Proof by truth table (F is False, T is True): p q r (p == q) (q == r) ((p == q) == r) (p == (q == r)) F F F T T F F F F T T F T T F T F F F T T F T T F T F F T F F F T T T T F T F F F F T T F T F F F T T T T T T T That proves associativity of (==). Also note that p /= q ≡ not p == q. Proof: p q (p /= q) (not p) (not p == q) F F F T F F T T T T T F T F T T T F F F And by symmetry of (/=), p /= q ≡ p == not q. Then: (p /= q) /= r ≡ (not p == q) == not r ≡ not p == (q == not r) ≡ p /= (q /= r). Hence (/=) is associative. Q.E.D.

5 7

Add fixity for (==) and (/=)
by Dannyu NDos 18 Sep '18

18 Sep '18

Given that they are instantized for `Bool`s, they are associative, so it seems approvable to give them a fixity. (Sidenote: For the monoid over (==) I suggested on last May, I stated that it determines if there is an even number of `True`s, but that's wrong. It determines if there is an odd number of `False`s.)

3 2

GC-Managed ByteArray Slicing
by Andrew Martin 08 Sep '18

08 Sep '18

In GHC Haskell, there are two common options for working with bytes in memory: data ByteArray = ByteArray ByteArray# data ByteSlice = ByteSlice ByteArray# Int# Int# The second one, ByteSlice, is roughly what the bytestring library does (but with a ForeignPtr instead of a ByteArray# inside of it). What's unfortunate is that it's difficult to know which of these two types is going to provide better performance for a given application. These heuristics are helpful for guiding the process: 1. The longer the data is going to be around, the better the unsliced variant will be. This point is about space efficiency. The sliced variant needs two extra machine words to hold those indices, plus it holds on to extra bytes from the array that it is slicing into. 2. The shorter the data is going to be around, the better the sliced variant is. This point is about speed of execution. The cost of the unsliced variant is typically a memcpy. If the data is getting GCed quickly anyway, the unsliced copy doesn't save you any space. 3. The shorter the data is, the better the unsliced variant is. 4. The more sharing of the data there is, the better the sliced variant is. But, users have to commit to which one they want to use in their data type definitions, and the data type may be used in different contexts where one or the other is preferable. For example, consider the following: data Student = Student { name :: {-# UNPACK #-} !BytesType , grade :: {-# UNPACK #-} !Int } Which of the two types should we use for BytesType? (For this example, ignore the incorrectness of using bytes to represent text. With either of the two bytes types, it's easy to put a newtype on top that communicates that what's inside is guaranteed to be UTF-8 encoded text). It depends on the usage. For example, consider that we are parsing students from this xml file: <students> <student> <name>Erica Chang</name> <grade>87</grade> </student> <student> <name>Lizbeth Cruz</name> <grade>91</grade> </student> ... </students> Let's say we've got about 1GB of this, and we run a parser on 64KB chunks as they are read from disk. There are two contasting scenarios to consider. If the file is parsed at startup and the resulting array of students is kept in memory for a long time afterward, then the unsliced variant is better. It allows us to throw away all of the bytes corresponding to the xml nodes, which are no longer relevant. The sliced variant, by constrast, would keep the entire contents of the original file in memory. However, if the file is parsed by a SAX-style streaming parser, the students being parsed, processed, and then discarded as they encountered, the sliced variant is better. Slicing wins here because the chunks from the file are discarded shortly after they are encountered. Read "shortly" as "before the next minor GC". In this example, Student was an application-specific data type, so the application author could figure out what they were actually doing with the data and define the data type accordingly. However, this isn't always a solution. What if they needed to use the same type differently in different contexts? What if the type was provided by a library and the library author doesn't know how it will be used? So far, this has just been an explanation of a problem that I've noticed. I understand the problem well, but now I'm going to propose a solution. There are a lot of holes in my understanding of GHC's runtime, so I don't understand if what I'm proposing is actually plausible. What if the GHC's runtime handled the copy decisions for us? What if we had these primitives: data Bytes# sliceBytes# :: Bytes# -> Int# -> Int# -> Bytes# lengthBytes# :: Bytes# -> Int# Slicing causes the runtime to track that there is an additional reference to the byte array but that the offset and length are different. I'm not sure where this information would be stored though. When GC runs, it would copy slices from bytes if the there were no longer any references to the entire array. So a single type could serve the both purposes discussed in the scenario above. I'm not sure what kind of impact this might have on GC time. -- -Andrew Thaddeus Martin

2 1

Proposal: Add mapAccumLM and mapAccumRM to Data.Traversable
by Reed Mullanix 03 Sep '18

03 Sep '18

I propose adding a pair of functions to Data.Traversable: mapAccumLM and mapAccumRM with the type '(Traversable t, Monad m) => (a -> b -> m (a,c)) -> a -> t b -> m (a, t c)'. These would behave exactly the same as mapAccumL and mapAccumR, but would allow the addition of monadic effects. This would allow the traversal of structures with an accumulator, without resorting to using foldlM or foldrM, both of which require the extra boilerplate of reconstructing the structure after applying the action, which can be somewhat frustrating and error-prone. A possible implementation would be to add transformer counterparts to StateL/StateR in Data.Functor.Util: (gist: https://gist.github.com/TOTBWF/dc6020be28df7b00372ab8e507aa54b7) newtype StateLT s m a = StateLT { runStateLT :: s -> m (s,a) } instance (Functor m) => Functor (StateLT s m) where fmap f (StateLT k) = StateLT $ \s -> fmap (\(s',a) -> (s', f a)) $ k s instance Monad m => Applicative (StateLT s m) where pure a = StateLT $ \s -> return (s, a) StateLT kf <*> StateLT kv = StateLT $ \s -> do (s', f) <- kf s (s'', v) <- kv s' return (s'', f v) liftA2 f (StateLT kx) (StateLT ky) = StateLT $ \s -> do (s', x) <- kx s (s'', y) <- ky s' return (s'', f x y) mapAccumLM :: (Monad m, Traversable t) => (a -> b -> m (a,c)) -> a -> t b -> m (a, t c) mapAccumLM f s t = runStateLT (traverse (StateLT . flip f) t) s newtype StateRT s m a = StateRT { runStateRT :: s -> m (s,a) } type StateR s = StateRT s Identity instance (Functor m) => Functor (StateRT s m) where fmap f (StateRT k) = StateRT $ \s -> fmap (\(s',a) -> (s', f a)) $ k s instance Monad m => Applicative (StateRT s m) where pure a = StateRT $ \s -> return (s, a) StateRT kf <*> StateRT kv = StateRT $ \s -> do (s', v) <- kv s (s'', f) <- kf s' return (s'', f v) liftA2 f (StateRT kx) (StateRT ky) = StateRT $ \s -> do (s', y) <- ky s (s'', x) <- kx s' return (s'', f x y) mapAccumRM :: (Monad m, Traversable t) => (a -> b -> m (a,c)) -> a -> t b -> m (a, t c) mapAccumRM f s t = runStateRT (traverse (StateRT . flip f) t) s

2 1

Mark partial functions as such
by Richard Eisenberg 01 Sep '18

01 Sep '18

Proposal: Mark partial functions in `base` as partial Motivation: I'm about to teach Haskell to a classful of beginners. In my experience, they will soon reach for functions like `head` and `tail`, because pattern-matching is foreign to them. I would love just to be able to say "Don't use partial functions", but many students will not easily be able to tell partial functions from total ones. I do expect this problem to work itself out rather quickly, and then students will be able to identify partial functions, but loudly marking partial functions as partial seems like a small service to everyone and a bigger one to newbies. I don't see any downsides. Thoughts? Thanks, Richard

17 29