- Libraries - Haskell.org

Proposal: add -XPolyKinds to Data.Monoid
by Carl Howells 15 Jul '14

15 Jul '14

At the moment, the Monoid instance for Data.Proxy.Proxy is only defined for types with kind *. Prelude Data.Proxy Data.Monoid> (Proxy :: Proxy String) <> Proxy Proxy Prelude Data.Proxy Data.Monoid> :set -XDataKinds Prelude Data.Proxy Data.Monoid> (Proxy :: Proxy 5) <> Proxy <interactive>:8:20: No instance for (Monoid (Proxy 5)) arising from a use of ‘<>’ In the expression: (Proxy :: Proxy 5) <> Proxy In an equation for ‘it’: it = (Proxy :: Proxy 5) <> Proxy Enabling -XPolyKinds while compiling the Data.Monoid module is the only change necessary to make the Monoid instance for Proxy polykinded like Proxy itself is. I don't believe adding a language pragma would have any other effect on that module, and I believe the only effect of changing that instance would be allowing more correct programs to compile. This is my first proposal to this list, so I'm starting with something that I hope isn't controversial. Let me know if I should do anything different procedurally in future proposals. Thanks.

5 7

Bit shifting limitations
by David Feuer 14 Jul '14

14 Jul '14

The current state of affairs is a bit unsatisfactory. 1. The biggest problem, as I see it, is that while we have shiftR and shiftL, which are documented as giving 0 or -1 when shifting too far, and we have unsafeShiftR and unsafeShiftL, which are likely to do whatever the CPU happens to do, we don't have anything guaranteed to shift using just the first five or six bits of the shift count, which is what Java specifies and what unsafeShiftR and unsafeShiftL *actually* do (at least on x86_64). I propose that we add these masked shifts to Data.Bits. The default implementations can look something like: shiftRMasked x count | popCount (finiteBitSize x) != 1 = error "Masked shift only makes sense if the size is a power of 2." | otherwise = x `unsafeShiftR` (count .&. (finiteBitSize x - 1)) 2. It would be nice to specify what shiftR and shiftL are supposed to do when given negative shift counts. Is there a practical reason not to specify that? 3. I would like to add explicit arithmetic and logical shifts to Data.Bits. When fiddling bits, it's often easier to think about that distinction explicitly, rather than in terms of whether the type is signed or unsigned, and more convenient to have an explicit operation rather than casting around. David

6 21

[ANNOUNCE] New Core Libraries Committee Members
by Edward Kmett 11 Jul '14

11 Jul '14

I'm pleased to announce that Eric Mertens and Luite Stegeman have joined the core libraries committee. http://www.haskell.org/haskellwiki/Core_Libraries_Committee Brent Yorgey and Doug Beardsley stepped down to make room. I'd like to thank them for helping us get the committee started. In the short term Eric will probably help out with moving the Applicative Monad Proposal forward and with the knock-on effects of that change, and Luite will join Joachim Breitner in trying to figure out the right path forward for the split base proposal. -Edward Kmett

1 0

Re: [Haskell-cafe] Requesting maintainership: bzlib-conduit and process-conduit
by Michael Snoyman 29 Jun '14

29 Jun '14

Oops, you're right. I've added libraries@ to the CC list. On Sun, Jun 29, 2014 at 7:12 PM, Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk> wrote: > On 06/29/2014 06:02 PM, Michael Snoyman wrote: > > I'd like to request to be granted maintainership of two conduit-related > > packages: bzlib-conduit and process-conduit. Both packages are maintained > > by the same author. I opened up a pull request[1] on bzlib-conduit back > in > > January, and haven't heard back yet. There's also an issue with > > process-conduit[2] which I'd like to address, but given the lack of > > response of bzlib-conduit, haven't sent a pull request yet. > > > > I also emailed the author directly five days ago regarding the > > bzlib-conduit pull request, and have not received a response. > > > > [1] https://github.com/tanakh/bzlib-conduit/pull/7 > > [2] https://github.com/tanakh/process-conduit/issues/14 > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > Two things: > > 1. Does this not need to go on libraries@ instead? > 2. I happen to know the author is an active Twitter user under the > ‘tanakh’. I will tweet him your e-mail but perhaps it's worth trying > that method of communication too. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Add instances for Functor, Monad, Applicative to Data.Monoid.First, Last
by Omari Norman 28 Jun '14

28 Jun '14

This was proposed in 2011: http://www.haskell.org/pipermail/libraries/2011-January/015552.html Any reason it did not go anywhere? Should I propose it again? Thanks. Omari

2 1

New version of vector + discussion
by Gregory Collins 26 Jun '14

26 Jun '14

Hi all, I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set. Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow: # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: Data/Vector.hs # deleted by them: Data/Vector/Fusion/Bundle/Monadic.hs # both modified: Data/Vector/Fusion/Stream.hs # both modified: Data/Vector/Fusion/Stream/Monadic.hs # both modified: Data/Vector/Fusion/Stream/Size.hs # both modified: Data/Vector/Generic.hs # both modified: Data/Vector/Generic/Mutable.hs # deleted by them: Data/Vector/Generic/Mutable/Base.hs # both modified: Data/Vector/Generic/New.hs # both modified: Data/Vector/Mutable.hs # both modified: Data/Vector/Storable.hs # both modified: Data/Vector/Unboxed.hs # both modified: Data/Vector/Unboxed/Base.hs # both added: README.md # both modified: benchmarks/vector-benchmarks.cabal # both added: changelog # both modified: internal/unbox-tuple-instances # both modified: tests/vector-tests.cabal # both modified: vector.cabal I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge? G -- Gregory Collins <greg(a)gregorycollins.net>

4 9

fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by davean 25 Jun '14

25 Jun '14

I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621 might have stalled but it seems like it has from my perspective. Can someone tell me I'm wrong or what to do to unstall it? This is very useful functionality that is actually part of IEEE Std 1003.1. -davean

3 7

Use -Werror by default on travis-ci
by Simon Hengel 18 Jun '14

18 Jun '14

Hi, I created a PR to use -Werror by default on travis-ci. If you think this is a good idea, see any issue or have any other input, get involved in the discussion on GitHub [1]. Cheers, Simon [1] https://github.com/travis-ci/travis-build/pull/250

1 0

setlocale maintainership
by adam vogt 16 Jun '14

16 Jun '14

Hello list. http://hackage.haskell.org/package/setlocale does not compile with ghc-7.8 because it has a manually written typeable instance. I emailed the author about this one month ago (May 15), but I have received no reply. Let us wait until September 1 2014, and then I could be allowed to upload a corrected version? Regards, Adam

6 8

List.or, List.any and List.elem
by Andreas Abel 12 Jun '14

12 Jun '14

Curious on whether I should prefer List.any f over List.or . List.map f I consulted the source code at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-List.html I found that according to the Report, they are identical, but there are fusion rules for List.any which look like I should prefer it to the said composition. What puzzled me is that later, List.elem x is List.any (x ==) according to the Report, but GHC defines it recursively, *without* fusion rules. I wonder Q1: Should I prefer List.any (x==) then, since it gives opportunity to fusion? Q2: Why is then List.elem defined recursively? Q3: Where is the comment that justifies the taken design decisions?? Cheers, Andreas #ifdef USE_REPORT_PRELUDE any p = or . map p all p = and . map p #else any _ [] = False any p (x:xs) = p x || any p xs all _ [] = True all p (x:xs) = p x && all p xs {-# NOINLINE [1] any #-} {-# NOINLINE [1] all #-} {-# RULES "any/build" forall p (g::forall b.(a->b->b)->b->b) . any p (build g) = g ((||) . p) False "all/build" forall p (g::forall b.(a->b->b)->b->b) . all p (build g) = g ((&&) . p) True #-} #endif -- | 'elem' is the list membership predicate, usually written in infix form, -- e.g., @x \`elem\` xs@. For the result to be -- 'False', the list must be finite; 'True', however, results from an element equal to @x@ found at a finite index of a finite or infinite list. elem :: (Eq a) => a -> [a] -> Bool -- | 'notElem' is the negation of 'elem'. notElem :: (Eq a) => a -> [a] -> Bool #ifdef USE_REPORT_PRELUDE elem x = any (== x) notElem x = all (/= x) #else elem _ [] = False elem x (y:ys) = x==y || elem x ys notElem _ [] = True notElem x (y:ys)= x /= y && notElem x ys #endif -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

1 0