- Libraries - Haskell.org

Proposal: accum and accumArray strictness
by David Feuer 09 Feb '18

09 Feb '18

The documentation for accumArray is currently broken [*]. According to the documentation: According to the documentation, > If the accumulating function is strict, then 'accumArray' is strict in > the values, as well as the indices, in the association list. Thus, > unlike ordinary arrays built with 'array', accumulated arrays should > not in general be recursive. I believe that purported strictness is desirable, because it prevents thunks from accumulating when we use the passed function. But the strictness *isn't really there*. accumArray never forces any values whatsoever! The same is true of accum, but that function does not document its strictness. I propose that we change both the implementation and documentation. For accumArray, I think we should say that the resulting array is strict in the initial value and in each result of applying the accumulating function, and indicate that each element of the resulting array will be in WHNF. For accum, I think we should say that the resulting array is strict in each value in the initial array and in each result of applying the accumulating function, and indicate that each element of the resulting array will be in WHNF. We thereby guarantee that we can accumulate strictly, which is important for performance, and I think being strict in the initial value(s) makes for simpler reasoning than only being strict in the results of the combining function. [*] https://ghc.haskell.org/trac/ghc/ticket/14785 David Feuer

1 1

Formal verification of containers
by Joachim Breitner 08 Feb '18

08 Feb '18

Hi containers maintainers, you might have already read it between the lines, but some people here at Penn are currently using hs-to-coq to translate the containers library to Coq and verify it. We just reached a milestone by verifying a portion of Data.IntSet large enough to instantiate Coq’s FSetInterface: https://github.com/antalsz/hs-to-coq/blob/master/examples/containers/theori… There is work on verifying Data.Set as well: https://github.com/antalsz/hs-to-coq/blob/master/examples/containers/theori… Isn’t that exciting? It raises the question whether there is value in integrating these proofs in some way into the development process of containers. One could imagine adding a job to travis that translates container’s master into Coq and checks if the proofs go through. On the one hand, that’s of course great, because it’d make containers one of the most thoroughly verified pieces of Haskell in use out there. On the other hand, we’d have to choose the least bad of a bunch of bad options when it comes to future contributions (I am listing unfeasible options as well): - we essentially freeze the code - we’d lose the verification again quickly, once someone makes a non- trivial change to the code - we’d have to restrict contributions to those who are able to update the proofs - we’d still welcome contributions that break the proofs, but let them sit in pull requests until someone updates the proofs on the PR and then merge - (maybe a bit far fetched, but who knows) we get funding to pay someone to keep the proofs in sync, without slowing down other contributions I honestly don’t know which of these are the most viable, or if none of them make any sense and we should not hook up the verification with container’s development. What do you think? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 13

Preventing double-free error with `stablePtr`
by Gershom B 06 Feb '18

06 Feb '18

I was just reading Roman Cheplyaka’s very interesting blog-post here: https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior. As he points out, the docs for `freeStablePtr` say "if the stable pointer is passed to deRefStablePtr or freeStablePtr, the behaviour is undefined.” And indeed we can observe weird behavior as a result of sucn an error. A deRef of a stable pointer is arguably the sort of sharp-edge we know how to code to avoid. But a double free is a bit trickier. Would it be worth adding a bit more overhead to make such an operation idempotent? Additionally, would it be worthwhile to add `withStablePtr` to the `Foreign.StablePtr` module? I imagine there are cases that it won’t cover, but it would at least encourage good discipline in the cases that it does handle. The evident utility of such a function is witnessed by its existence in a few different codebases, not least the Win32 library ( https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.h… ) Cheers, Gershom

4 3

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