April 2016 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

Proposal: add chunksOf to Data.Sequence
by David Feuer 06 May '16

06 May '16

Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements each. The internal "splitMap" function Data.Sequence uses to implement zipWith supports a simple and efficient implementation of chunksOf. All in favor, say "aye". Also, I'm still waiting for a response (any response) to my "cycleN" proposal. David

5 6

Re: Discussion: reconsider lens-like exports from containers
by David Feuer 28 Apr '16

28 Apr '16

AHA! I was wrong! There *is* (some) hope! I should've realized this earlier. The trick is to use Coyoneda instead of Yoneda. Coyoneda is effectively lazier than Yoneda, so nodes can become available as soon as they're passed. I suspect it may also be helpful that while liftYoneda is pricier than lowerYoneda for non-trivial functors, the opposite holds for Coyoneda. Since adjustA does a lot more lifting than lowering, Coyoneda seems like a better fit. A thoroughly straightforward Coyoneda-based implementation offers *decent* (although not wonderful) viewing performance. But as soon as it's passed something that reads *and* modifies, it does a little better than the fake version. On Wed, Apr 27, 2016 at 10:15 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Using Yoneda greatly improved performance for Identity, and raised the > performance for [] a little above that of the "fake" version lens > currently uses. But the performance for simply viewing an element is > awful (it takes about twice as long as `index`), and I'm beginning to > doubt there's any solution that will get the (small) speed-up in some > cases without getting a (large) slow-down elsewhere. Oh well. > > On Wed, Apr 27, 2016 at 6:39 PM, Edward Kmett <ekmett(a)gmail.com> wrote: >> That transformation is effectively what 'fusing' does. It CPSes (er.. >> Yonedas, actually) the functor `f` as forall r. (a -> r) -> f r, and >> accumulates the changes by composing in more functions, so that it can >> all be discharged with one fmap. You should be able to achieve the >> same result by hand with a manual worker/wrapper transformation. >> >> -Edward >> >> On Thu, Apr 28, 2016 at 8:20 AM, David Feuer <david.feuer(a)gmail.com> wrote: >>> I was thinking switching to CPS might help, passing the context down on the >>> way to the leaf, so the tree is built "inside" the functor. This is pretty >>> easy for nodes and digits, but I'm struggling with the polymorphic recursion >>> in the spine right now. I think I'll probably figure it out eventually. >>> >>> On Apr 27, 2016 6:12 PM, "Edward Kmett" <ekmett(a)gmail.com> wrote: >>>> >>>> For cases were the Functor winds up particularly complicated or won't >>>> be known at compile time so the inlining can't help, it turns out you >>>> can usually work around this with the 'fusing' combinator from the >>>> lens library. This works around the repeated stacks of `fmap` that get >>>> built up otherwise, transforming everything into one gigantic fmap all >>>> in one go. >>>> >>>> There is a similar `confusing` combinator for working with traversals. >>>> The implementation lives up to the name. >>>> >>>> -Edward >>>> >>>> On Wed, Apr 27, 2016 at 5:19 PM, <rf(a)rufflewind.com> wrote: >>>> > On Tue, Apr 26, 2016, at 15:03, David Feuer wrote: >>>> >> Way back when, Shachaf Ben-Kiki suggested an efficient implementation >>>> >> of `at` for Data.Map in >>>> >> https://mail.haskell.org/pipermail/libraries/2013-May/019761.html but >>>> >> that was never approved for inclusion. >>>> > >>>> > Funny thing, I just tried doing that not to long ago with `at`: >>>> > >>>> > https://github.com/haskell/containers/pull/192 >>>> > >>>> > In the end, the results were mixed. It was a small optimization in some >>>> > situations, and a moderate pessimization in others (esp. when the >>>> > Functor becomes too complex for GHC to optimize). >>>> > >>>> > -- >>>> > RF >>>> > _______________________________________________ >>>> > 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 2

ANN: Haskell Prime 2020 committee has formed
by Herbert Valerio Riedel 28 Apr '16

28 Apr '16

Dear Haskell Community! Some time ago I asked for nominations to reboot the Haskell Prime process[1], and now I'm pleased to finally announce the formation of the new Haskell Language 2020 Committee! The goal of the Haskell Language committee together with the Core Libraries Committee is to work towards a new Haskell 2020 Language Report. I'd like to remind everyone that the Haskell Prime Process[4] relies on *everyone* in the community to help by contributing proposals which the committee will then evaluate and if suitable help formalise for inclusion. Everyone interested in participating is also invited to join the haskell-prime mailing list. Four years (or rather ~3.5 years) from now may seem like a long time. However, given the magnitude of the task at hand, to discuss, formalise, and implement proposed extensions (taking into account the recently enacted three-release-policy[3]) to the Haskell Report, the process shouldn't be rushed. Consequently, this may even turn out to be a tight schedule after all. However, it's not excluded there may be an interim revision of the Haskell Report before 2020. Based on this schedule, GHC 8.8 (likely to be released early 2020) would be the first GHC release to feature Haskell 2020 compliance. Prior GHC releases may be able to provide varying degree of conformance to drafts of the upcoming Haskell 2020 Report. The Haskell Language 2020 committee starts out with 20 members which contribute a diversified skill-set. These initial members also represent the Haskell community from the perspective of practitioners, implementers, educators, and researchers. - Andres Löh - Antonio Nikishaev - Austin Seipp - Carlos Camarao de Figueiredo - Carter Schonwald - David Luposchainsky - Henk-Jan van Tuyl - Henrik Nilsson - Herbert Valerio Riedel - Iavor Diatchki - John Wiegley - José Manuel Calderón Trilla - Jurriaan Hage - Lennart Augustsson - M Farkas-Dyck - Mario Blažević - Nicolas Wu - Richard Eisenberg - Vitaly Bragilevsky - Wren Romano The Haskell 2020 committee is a language committee; it will focus its efforts on specifying the Haskell language itself. Responsibility for the libraries laid out in the Report is left to the Core Libraries Committee (CLC)[5]. Incidentally, the CLC still has an available seat[2]; if you would like to contribute to the Haskell 2020 Core Libraries you are encouraged to apply for this opening. As this is a general announcement broadcasted to multiple mailing lists, a separate email discussing the next steps of the new committee will be sent to the haskell-prime mailing list shortly. [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/libraries/2015-November/026497.html [3]: https://prime.haskell.org/wiki/Libraries/3-Release-Policy [4]: https://prime.haskell.org/wiki/Process [5]: https://prime.haskell.org/wiki/Libraries -- hvr

1 0

Discussion: reconsider lens-like exports from containers
by David Feuer 27 Apr '16

27 Apr '16

Way back when, Shachaf Ben-Kiki suggested an efficient implementation of `at` for Data.Map in https://mail.haskell.org/pipermail/libraries/2013-May/019761.html but that was never approved for inclusion. I believe I've come up with a somewhat nasty but efficient implementation of `ix` for Data.Sequence (hand-specialized and hand-unboxed), based on the code for `adjust`. See https://gist.github.com/treeowl/b80c2c490563765fc7881be30f3dba24 lens has continued to grow in popularity, so I think the time has probably come to talk again about adding `at` for Data.Map, and to talk about adding `ix` for Data.Sequence. Note: for consistency with the rest of the Data.Sequence API, `ix` would be named `adjustA`, and would have its first two arguments flipped. David Feuer

4 7

Re: Discussion: reconsider lens-like exports from containers
by David Feuer 26 Apr '16

26 Apr '16

I *believe* that the [] Applicative will prove that adjustA is sometimes more efficient than any implementation built on the current API. In that context, it should be possible to descend to a leaf once and then ascend from it many times. foo n xs = adjustA f n xs where f :: Char -> [Char] f x = ... This only travels to the nth element once and effectively saves the path to that spot so it can produce many sequences where that element is different. You could do something conceptually similar by splitting the sequence at that point and putting the pieces together many times, but in practice that would be awful. On Apr 26, 2016 3:18 PM, "Marcin Mrotek" <marcin.jan.mrotek(a)gmail.com> wrote: Hello, I don't feel qualified to take a stance on this, but since you did make a comment about "deafening silence" earlier on an unrelated issue, then, if this `adjustA` doesn't depend on any particular Lens library, and it's more efficient than any hand-rolled solution, then why not? Best regards, Marcin Mrotek

1 0

Proposal: Add rtsIsThreaded to base
by Merijn Verstraaten 26 Apr '16

26 Apr '16

I would propose adding a Bool value to base that indicates whether the code was compiled/linked with the threaded or single threaded runtime system. A library might want to implement certain functionality differently depending on whether the threaded runtime system is used (i.e. avoid blocking C FFI calls in single-threaded). There is currently no good way to do this. StackExchange currently suggests using "Control.Concurrent.rtsSupportsBoundThreads" for this, which is defined as: HsBool rtsSupportsBoundThreads(void) { #if defined(THREADED_RTS) return HS_BOOL_TRUE; #else return HS_BOOL_FALSE; #endif } But it seems undesirable to conflate support for bound threads and use of the threaded runtime system? Especially since this would be a trivial addition to Control.Concurrent (i.e. simply an ifdef'ed True/False constant). Cheers, Merijn

2 2

Proposal: Export cycleN from Data.Sequence
by David Feuer 26 Apr '16

26 Apr '16

Yesterday I rewrote `*>` for Data.Sequence (again), using an internal function cycleN :: Int -> Seq a -> Seq a The name of the function is based on that of Data.Sequence.iterateN. cycleN takes a sequence and cycles it as many times as requested: cycleN 0 $ fromList [1,2] = [] cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] The function is written to maximize sharing in the result sequence and to minimize construction time. Specifically, cycleN n xs should take something like O(|xs| + log n) space (of which all but O(log |xs| + log n) is shared with the structure of xs) and O(log |xs| + log n) time. With current (on GitHub) Data.Sequence exports, the only way to get this functionality with these time and space bounds is to combine replicate with *> : cycleN n xs = replicate n () *> xs This strikes me as a bit unpleasant. David

3 3

Dropping support for NHC98 and old GHC from containers
by David Feuer 25 Apr '16

25 Apr '16

The containers package currently includes CPP and Cabal directives intended to support NHC98 and versions of GHC before 7.0. However, our TravisCI script tests only GHC versions 7.0 and above. It is therefore likely that the compatibility code is bit-rotted to some extent. Wren Romano and I are strongly inclined to immediately remove all code intended to support NHC98 or pre-7.0 GHC. If anyone uses any such implementations with the current version of containers, please speak now or forever hold your peace. Thanks, David Feuer

3 2