- Libraries - Haskell.org

generalize type of Data.Set.unions from List to Foldable
by Johannes Waldmann 05 Feb '18

05 Feb '18

Dear Libraries, I propose this change for containers: have: unions :: [ Set a ] -> Set a want: unions :: Foldable f => f (Set a) -> Set a and similar for unions in IntSet, Map, IntMap. Since this affects the public API, contributor guidelines require to go through this mailing list. See https://github.com/haskell/containers/issues/520 NB: the only other places in Data.Set (etc.) where a list occurs in an argument position are the from*List[With] functions. - J.W.

7 13

Removing bitSize
by David Feuer 04 Feb '18

04 Feb '18

The long-deprecated bitSize method of the Bits class is slated to be removed in base-4.11 (GHC 8.4). There is one remaining question: should we replace it with a *function* by that name with a FiniteBits constraint? I don't feel very strongly either way, but Ryan Scott seems in favor and Edward Kmett seems opposed. So it seems best to bring it to the libraries list and let the CLC make the call. If the function is added, it would look like this: bitSize :: FiniteBits a => a -> Int bitSize = finiteBitSize The biggest downside I see is that we might one day want to reuse the name for something with a better type, such as bitSize :: forall proxy a. FiniteBits a => proxy a -> Int bitSize _ = finiteBitSize (undefined :: a) or bitSize :: forall a. FiniteBits a => Tagged a Int bitSize = Tagged (finiteBitSize (undefined :: a)) or (with type applications) bitSize :: forall a. FiniteBits a => Int bitSize = finiteBitSize (undefined :: a) Thanks, David Feuer

5 5

Combinators for Show
by Li-yao Xia 30 Jan '18

30 Jan '18

Hello libraries, base contains a small combinator library for Read, but there doesn't seem to be a similar thing for Show. Offering a few more convenient helpers to avoid dealing with whitespace and especially precedence levels seems straightforward enough. Is there an API somewhere that I missed? Has there been a proposal/discussion about this before? I'm ready to make one otherwise. Li-yao

3 3

Name of 1-Tuple Data Type
by Andrew Martin 29 Jan '18

29 Jan '18

Required background information: https://ghc.haskell.org/trac/ghc/ticket/14673 GHC has a one-tuple (both a boxed variant and an unboxed variant). The unboxed variant currently must be fully applied whenever it is used. This is in stark contrast to all the other n-tuples (n > 1). It stems entirely from an issue of syntax. The solution decided on is to provide a normal prefix name for the 1-tuple. The name that GHC uses internally for this type is `Unit#` (there is also a boxed variant Unit). However, in the haskell community, the word "unit" already refers to the nullary tuple, not the unary tuple. So, we're bikeshedding the name. Here are some possible options: * Unary (as in unary tuple) * Single (as in single, double, triple) * Singleton (as is singleton, doubleton, tripleton) * Only ( https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html) * OneTuple ( https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple… ) * Uni (means "one" in latin or greek or something like that) * Mono (means "one" in latin or greek or something like that) I would appreciate any feedback on the suggestions I provided or any additional suggestions for the name. If you have concerns about the feature itself, comment on the GHC Trac ticket. I'd prefer to keep this thread focused on just the problem of coming up with a name. -- -Andrew Thaddeus Martin

13 20

Crazy suggestion for dealing with the naming disaster that is ByteString
by Merijn Verstraaten 28 Jan '18

28 Jan '18

Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything. But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes". Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever. Cheers, Merijn

4 4

Taking over maintainership of exact-pi
by Andrew Lelechenko 27 Jan '18

27 Jan '18

I would like to take over `exact-pi` package (https://hackage.haskell.org/package/exact-pi) Unfortunately, the package became incompatible with upcoming GHC 8.4 and needs an upgrade. The relevant pull request (https://github.com/dmcclean/exact-pi/pull/5) prepared by @konn, has been open for a month without response. I also tried to reach its maintainer Douglas McClean (cced) by email, but have not heard back. I am so interested in upgrading `exact-pi`, because it is a dependency of my package `arithmoi`. — Best regards, Andrew

3 2

Fwd: Re: generalized IntMap - IntegerMap or IntegralMap
by David Feuer 22 Jan '18

22 Jan '18

---------- Forwarded message ---------- From: "David Feuer" <david.feuer(a)gmail.com> Date: Jan 22, 2018 1:42 PM Subject: Re: generalized IntMap - IntegerMap or IntegralMap To: "Oliver Charles" <ollie(a)ocharles.org.uk> Cc: That would help, in theory. But backpack is a bleeding-edge experimental GHC feature, and containers has a long history of striving for relative portability. So for now we need to stick to CPP and whatever other widely-available preprocessors we want. On Jan 22, 2018 1:38 PM, "Oliver Charles" <ollie(a)ocharles.org.uk> wrote: > Would backpack be at all useful here? Seems you want to parameterise the > map by choice of numeric type. > > On 22 Jan 2018 3:59 pm, "David Feuer" <david.feuer(a)gmail.com> wrote: > >> I wish I knew. There are some loose ends that need to be tied up and >> unfortunately I have no sense of whether that's happening. >> >> On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail(a)joachim-breitner.de> >> wrote: >> >>> Hi, >>> >>> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer: >>> > Jonathan S. has been working (on and off) on a wholesale replacement >>> for IntMap. >>> >>> what is the plan here? I am currently in the process of formally >>> verifying IntSet (and later IntMap), so I am curious about what is >>> going to change here. >>> >>> Cheers, >>> Joachim >>> >>> -- >>> Joachim Breitner >>> mail(a)joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> 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 >> >>

2 1

generalized IntMap - IntegerMap or IntegralMap
by Henning Thielemann 22 Jan '18

22 Jan '18

I want to use Word32 or Word64 bit patterns as indices for a Map. I have checked that IntMap is more efficient than Map in my application. However, the Haskell 98 report warrants only 30 bits for Int including the sign bit. Is there a generalization of IntMap for Map Integer or (Integral k, Bits k) => Map k or would there be general interest in such a data structure?

4 8

ANNOUNCE: servant-pandoc 0.5.0.0
by Ivan Lazar Miljenovic 16 Jan '18

16 Jan '18

I'm pleased to announce the latest release of the servant-pandoc library: https://hackage.haskell.org/package/servant-pandoc-0.5.0.0 servant-pandoc allows you to take the documentation created with servant-docs and use Pandoc to convert it into whichever format you want (rather than the Markdown generated by servant-docs). The main changes in this release are to provide compatibility with servant-docs-0.11.1; specifically, servant-pandoc now emits all the information that servant-docs does with the same configuration options. As such, there are behavioural changes which necessitated the major version bump. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Taking over maintainership of cabal2spec
by Peter Simons 16 Jan '18

16 Jan '18

Fellow Haskell Hackers, I would like to take over the package cabal2spec [1], which hasn't seen any activity in the last 9 years. I have tried to contact the Hackage maintainers Conrad Meyer and Yaakov M. Nemoy to get them involved in the decision, but unfortunately I was unable to reach either one of them. Best regards, Peter [1] http://hackage.haskell.org/package/cabal2spec

2 2