- Libraries - Haskell.org

FW: Contributing to gamma Haskell package
by Alexandre Rodrigues 28 Oct '18

28 Oct '18

Greetings list; I am interested the `gamma ` package (http://hackage.haskell.org/package/gamma) having sent an email about a month ago to the current maintainer about contributing to the package. I am following package takeover procedures<https://wiki.haskell.org/Taking_over_a_package> by posting here, and stating my intentions publicly. Email: ________________________________ From: Alexandre Rodrigues <alexandreR_B(a)outlook.com> Sent: Thursday, September 27, 2018 5:01:50 PM To: mokus(a)deepbondi.net Subject: Gamma Haskell package Hello Mr. Cook; My name is Alexandre, and I’m writing this email to you concerning the Haskell `gamma` package<https://hackage.haskell.org/package/gamma> that you wrote and uploaded to Hackage. The last commit in the package’s GitHub repository was over 6 years ago. A few other packages also depend on this one, but they all seem deprecated. My question is if you have any plans for this package, and if you would accept my contributions to it. The reason why I ask this is because I am a contributor to another Haskell number theory package called `arithmoi`<https://github.com/cartazio/arithmoi>, and the gamma function is a useful tool to have at times. To finalize, I apologize for the unexpected email, and appreciate the time you took to read it. Regards, Alexandre

1 0

Fwd: Re: Adding dup to Data.Tuple?
by Ivan Perez 28 Oct '18

28 Oct '18

Forgot to CC the list. -------- Forwarded Message -------- Hi, One place where it pops up all the time is when you have arrows that create feedback loops and your output is your accumulator. For example: feedback acc0 (someFancyArrow >>> arr dup) Where someFancyArrow is an arrow with two inputs (input and old accumulator) and one output. Cheers Ivan On 28/10/18 00:08, Vanessa McHale wrote: > Out of curiosity, do you have any examples? > > Cheers > > On 10/27/18 5:03 PM, Ivan Perez wrote: >> Dear all, >> >> The function \x -> (x,x) is very convenient when working with arrows. >> >> Would it be appropriate to add it to Data.Tuple? >> >> Cheers, >> >> Ivan >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

package takeover: patience
by Daniel Cartwright 26 Oct '18

26 Oct '18

I have an interest in the `patience` package ( http://hackage.haskell.org/package/patience) and have sent an email some 2.5 weeks ago, to the current maintainer with regards to taking over responsibility of the package. I am following package takeover procedures by posting here, and stating my intentions publicly. Emails: Daniel Cartwright <chessai1996(a)gmail.com> Mon, Oct 1, 2:07 PM to mcallister.keegan Hi, I am emailing you about the patience library, of which you appear to be a maintainer. There is no issue tracker available for this library for some reason, so i am emailing you directly instead. Could you edit the package so that it compiles with the newest containers? If you put up the code somewhere it's possible I could make the change myself. Thanks, chessai --------------------------------------------------------------------------------------------------------------------- Daniel Cartwright <chessai1996(a)gmail.com> Mon, Oct 8, 5:29 AM to Keegan Hello, I would like to take over maintenance responsibility of patience. If you could give me hackage permissions for the package, that would be much appreciated. You can do this in one of two ways: 1. From the package maintainer group page on hackage: http://hackage.haskell.org/patience/maintainers/ Follow the "edit" link and add my username, "chessai", to the group. OR 2. You can email the hackage administrators (admin(a)hackage.haskell.org) saying you want "chessai" to take over the package, or at least want me to be allowed to upload new version. Thank you for your time!

1 0

MonadFail instance for Either
by Daniel Bergey 25 Oct '18

25 Oct '18

Is there still consensus in favor of adding this instance? instance IsString str => MonadFail (Either str) where fail = Left . fromString In 2016 there was some discussion, and my reading is that there was consensus in favor at the time: Trac: https://ghc.haskell.org/trac/ghc/ticket/12160 libaries mailing list: https://mail.haskell.org/pipermail/libraries/2016-August/027248.html Does anyone know of a later decision not to add it, or was it simply no one's top priority? What is the next step to move this proposal forward? Is more discussion in order? Should I just submit a patch? Thanks, bergey

5 9

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 03 Oct '18

03 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 20 Sep '18

20 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