March 2015 - Libraries

Hackage trustee proposal: Curating the Hackage package collection
by Adam Bergmark 31 Mar '15

31 Mar '15

Dear Haskell Community, For some time Hackage has contained a user group called "Trustees", http://hackage.haskell.org/packages/trustees/ . Description: The role of trustees is to help to curate the whole package collection. Trustees have a limited ability to edit package information, for the entire package database (as opposed to package maintainers who have full control over individual packages). Trustees can edit .cabal files, edit other package metadata and upload documentation but they cannot upload new package versions." In short, making sure that packages keep building and filling the gap between unreachable maintainers and package take-overs. Up until now we have been very careful with changes since we haven't had a defined process. Spurred by SPJ and others we have been working on a proposal for how we should operate. You can find the proposal here: https://gist.github.com/bergmark/76cafefb300546e9b90e We would now like your feedback! Some specific things from the proposal that we'd like your opinion on: * Section 1: No opt-out for restricting bounds * Section 2: Opt-out rather than opt-in procedure for loosening version constraints * Section 2: Do you care whether you are notified before or after a version constraint is loosened? * Section 3: The time frame for publishing simple source changes * Section 3: What exactly should constitute a "simple source change" We also have a github repository where YOU can file issues about broken packages, you can start doing this right now! https://github.com/haskell-infra/hackage-trustees/ Please share this with as many people as possible. We are looking forward to hear your thoughts! Sincerely, Adam Bergmark

2 1

Library_submissions and Call for Maintainers
by Edward Kmett 30 Mar '15

30 Mar '15

We've had a lot of feedback over the last few months trying to get clarification on the role of the core libraries committee, and on the libraries@ process in general. In particular, Simon Peyton Jones asked us in his own rather inimitable manner to make sure that we sat down and started documenting things. After all, we've now been at this for almost a year and a half, and have started to figure out what is working and what isn't. In response to that feedback, we've recently taken the time to go through and update the Library_submissions <https://wiki.haskell.org/Library_submissions> page rather extensively to better describe and refine the libraries@ process and better define the role of the core libraries committee. Changes of note: * Up until now we've been using the rather ad hoc definition of "core libraries" as libraries that come with the Haskell Platform and which are subject to the libraries@ proposal process. We've recently taken it upon ourselves to clarify this further. To that end we've updated the Library_submissions <https://wiki.haskell.org/Library_submissions> page with a detailed summary of what libraries are considered "core" and why. * It was brought to our attention that figuring out even where to file a bug report or feature request for a given library was a tricky concern. To that end we've added information on how to find the appropriate issue tracker to the form. Communication: There are two forms of potential communication breakdowns that we'd like to address. We're still working on figuring out a more effective way to communicate what changes are happening in the background out to the community, lest we wind up with another situation like the Foldable/Traversable Proposal, where it caught an appreciable segment of the community unaware. We've started at least tracking issues that impact modules defined in the Haskell report in GHC trac with "report-impact", but we still have a lot more to do on this front. We have also been asked to help clarify what happens to a proposal once it leaves the libraries@ mailing list, assuming that the proposal is accepted by the maintainer. The issue was raised that it wasn't clear when an issue had been dropped on the floor, and who has responsibility to carry it forward at each stage along the way. To that end, we've posted some basic responsiveness guidelines <https://wiki.haskell.org/Library_submissions#Responsiveness> to help. We're not looking for a way to hold someone's feet to the fire, but merely for a way to keep proposals from getting stuck in limbo as they transition out of the libraries mailing list and into the hands of the maintainers. Maintainership: In an effort to maintain a greater level of throughput on issues that come along, we're trying to increase the number of projects that have active maintainers. Some of these aren't necessarily core libraries, but they are libraries that have been handed to the core libraries committee for maintenance. A couple of weeks back we sought out an active maintainer for the directory package, as it had accumulated several months worth of backlogged tickets, most of which just needed a clear head to make an informed decision about how to proceed. Phil Ruffwind and Elliot Robinson stepped up to fill this gap, and have been making a rather exciting amount of headway in clearing out the issue backlog, while managing to give those issues the consideration they are due. Emboldened by this success, we have a few other packages with which we'd like to do the same: * random We've had some truly excellent work done over the last couple of years on how to deal with "splitting" a random number generator in a cryptographically sound manner. I spent some time cleaning up a few outstanding issues for this package personally over the summer, but have not had nearly enough time to devote to the issue of how to integrate the outcome of the recent research on splitting, while simultaneously caring about performance and soundness. * unix We've had a number of issues accrete over time, particularly issues that have to do with portability to lesser used platforms such as OpenBSD. We've also had a lot of cooks in the kitchen, so the documentation style for this library is all over the place. We could use a solid maintainer for this package who is deeply familiar with unix internals, and who, preferably would like to deal with bringing some order to these cross platform concerns. * Win32 None of us on the current core libraries committee are *particularly* well versed in current windows issues. We have a new "windows task force" as well. Would the task force -- or someone involved or who would like to be involved in it -- be willing to pick this up and carry the torch? * old-time, old-locale, haskell98 and haskell2010 The old-time and old-locale libraries are primarily maintained because their contents are mentioned in the Haskell Report, which is/was (mostly) implemented in the haskell98 and haskell2010 packages. Three months ago, we determined to stop shipping these as boot libraries with the GHC as a consequence of the Applicative-Monad Proposal. (Issue #9590 <https://ghc.haskell.org/trac/ghc/ticket/9590>) While Herbert Valerio Riedel recently started working on a "fully compliant" version of the Haskell 2010 report, there is a reasonably large design surface in that area, balancing between perfect compatibility and pragmatic compatibility with other libraries. These libraries could use a more active official maintainer. Thank you for your time. Please do not hesitate to contact me (or reply) with questions, concerns, or thoughts. -Edward Kmett

10 17

Hidden Markov Models
by Dominic Steinitz 30 Mar '15

30 Mar '15

> I am currently working on > http://hub.darcs.net/thielema/hmm-hmatrix > > It does not need log-numbers because it normalizes all temporary results. > This way I can use fast hmatrix operations. Would normalization also be a > solution for other probabilistic models? I assume these are models with finite state spaces? FYI I uploaded a Kalman filter https://github.com/idontgetoutmuch/Kalman which is also a HMM. I feel we should be able to abstract over the Markov transition kernel to describe the model without caring whether the state space is continuous or discrete but that it is about as much thinking I have done on the subject. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Platform 2015.2.0.0 Alpha 2 for debian based systems
by Mark Lentczner 29 Mar '15

29 Mar '15

I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for generic debian linux systems. It includes GHC 7.10.2, using the generic linux bindist. This is a tarball, not a package. Installation instructions: cd / sudo tar xvf ...downloaded-tarfile... sudo /usr/local/haskell/ghc-7.10.1-x86-64/bin/activate-hs Notes: - Built on Ubuntu 14.04LTS - Needs the following packages installed: build-essential libbsd-dev libgmp-dev libtinfo-dev zlib1g-dev - The OpenGL packages need the OpenGL libs, which on a non-GUI system like a server can be gotten by installing: freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev - Mark

1 1

ANN: unification-fd 0.10.0
by wren romano 29 Mar '15

29 Mar '15

-------------------------------------------- -- unification-fd 0.10.0 -------------------------------------------- The unification-fd package offers generic functions for single-sorted first-order structural unification (think of programming in Prolog, or of the metavariables in type inference)[1][2]. The library *is* sufficient for implementing higher-rank type systems a la [Peyton Jones, Vytiniotis, Weirich, Shields], but bear in mind that unification variables are the metavariables of type inference--- not the type-variables. As of this version, the library is also sufficient for implementing (non-recursive) feature structure unification. An effort has been made to make the package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -------------------------------------------- -- Changes since 0.8.0 (2012-07-11) -------------------------------------------- * (0.8.1) Added Functor, Foldable, and Traversable instances for COntrol.Unification.Types.UnificationFailure. Thanks Graham Rogers. * (0.9.0) Changed the fundeps on BindingMonad and RankedBindingMonad so that things compule under GHC 7.8.2 * (0.9.0) eta-expanded the rewrite rules in Data.Functor.Fixedpoint so that GHC 7.8 no longer gives warnings about not firing due to (.) possibly being inlined first * Cleaned things up to compile cleanly for GHC 7.10 * For EitherK and MaybeK, liberalized the instances to only require Applicative instead of Monad wherever possible. * Completely revamped the old UnificationFailure data type as the new UFailure data type and Fallible type class. This was necessary to clean up some deprecation warnings about using Control.Monad.Error, to remove the hack of needing an UnknownError constructor, and to make the data type for representing failures more extensible. -------------------------------------------- -- Description -------------------------------------------- The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type Term = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked, or Nothing if this level doesn't match. Each subterm can be separately marked as being resolved, Left xy, or as requiring further unification, Right(x,y). class (Traversable t) => Unifiable t where zipMatch :: t a -> t a -> Maybe (t (Either a (a, a))) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the modified path compression as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -------------------------------------------- -- Notes and limitations -------------------------------------------- [1] At present the library does not appear amenable for implementing higher-rank unification itself; i.e., for higher-ranked metavariables, or higher-ranked logic programming. To be fully general we'd have to abstract over which structural positions are co/contravariant, whether the unification variables should be predicative or impredicative, as well as the isomorphisms of moving quantifiers around. It's on my todo list, but it's certainly non-trivial. If you have any suggestions, feel free to contact me. [2] At present it is only suitable for single-sorted (aka untyped) unification, a la Prolog. In the future I aim to support multi-sorted (aka typed) unification, however doing so is complicated by the fact that it can lead to the loss of MGUs; so it will likely be offered as an alternative to the single-sorted variant, similar to how the weighted path-compression is currently offered as an alternative. [3] With the exception of fundeps which are notoriously difficult to implement. However, they are supported by Hugs and GHC 6.6, so I don't feel bad about requiring them. Once the API stabilizes a bit more I plan to release a unification-tf package which uses type families instead, for those who feel type families are easier to implement or use. There have been a couple requests for unification-tf, so I've bumped it up on my todo list. -------------------------------------------- -- References -------------------------------------------- Luca Cardelli (1987) /Basic polymorphic typechecking/. Science of Computer Programming, 8(2):147--172. Atze Dijkstra, Arie Middelkoop, S. Doaitse Swierstra (2008) /Efficient Functional Unification and Substitution/, Technical Report UU-CS-2008-027, Utrecht University. <http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-027.pdf> Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields /Practical type inference for arbitrary-rank types/, to appear in the Journal of Functional Programming. (Draft of 31 July 2007.) Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman, and Amr Sabry (2005) /Backtracking, Interleaving, and/ /Terminating Monad Transformers/, ICFP. <http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf> Tim Sheard (2001) /Generic Unification via Two-Level Types/ /and Paramterized Modules/, Functional Pearl, ICFP. <http://web.cecs.pdx.edu/~sheard/papers/generic.ps> Tim Sheard & Emir Pasalic (2004) /Two-Level Types and/ /Parameterized Modules/. JFP 14(5): 547--587. This is an expanded version of Sheard (2001) with new examples. <http://web.cecs.pdx.edu/~sheard/papers/JfpPearl.ps> Wouter Swierstra (2008) /Data types a la carte/, Functional Pearl. JFP 18: 423--436. <http://www.cs.ru.nl/~wouters/Publications/DataTypesALaCarte.pdf> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unification-fd Darcs: http://community.haskell.org/~wren/unification-fd Haddock (Darcs version): http://community.haskell.org/~wren/unification-fd/dist/doc/html/unification… -- Live well, ~wren

1 0

ANN: stm-chans 3.0.0.3
by wren romano 29 Mar '15

29 Mar '15

-------------------------------------------- -- stm-chans 3.0.0.3 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes since 3.0.0 (2013-05-29) -------------------------------------------- Cleaned up the header gunk to compile cleanly under GHC 7.10. No actual code has been altered. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

wither the Platform
by Mark Lentczner 29 Mar '15

29 Mar '15

I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: *1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. *3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? — Mark

30 72

GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2
by Mark Lentczner 28 Mar '15

28 Mar '15

I have built the 7.10.1 bindist for OS X. It is currently sitting on my server at: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.10.1-x86_64-apple-darwin.tar.…> \O/ I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202015.2.0.0%20a…>. It is based on the above bindist. I should have an ubuntu version of the Platform built by tomorrow. \O/ - Mark *sha256 sums:* c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee ghc-7.10.1-x86_64-apple-darwin.tar.bz2 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg

4 5

Re: HP 2015.2.0.0 and GHC 7.10
by Mark Lentczner 28 Mar '15

28 Mar '15

*Hey you....* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day? I know, I know, our process is long and full of discussion, and hard, and slow.... let's smash that, eh? How'z'bout it? OKAY? Good! Your task is: - look over the the source file at GitHub <https://github.com/haskell/haskell-platform/blob/pre-release/hptool/src/Rel…> that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (copied below) - weigh in - short and sweet - if you have an opinion - if you have a spare Mac - download it and try it! <http://www.ozonehouse.com/mark/platform/> Crazy, right? I know... but, can we do this? — Mark On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 > using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the > Platform libs to the latest versions I could find on Hackage. There were a > few issues: > > - *old-locale and old-time* - no longer part of GHC, but > cabal-install, cgi & HTTP need them - and they are part of the platform - > so included now as added packages. Not sure this is a great idea, since > they are now very deprecated... but until cabal-install, cgi, & HTTP > update, not sure what else to do. > - *tf-random* - is now required by alex and QuickCheck - seems a shame > to add this, as now we're going to have two random packages > - *network-uri *- was split out of network, and needed by > cabal-install, cgi, & HTTP. I suppose we should include it, as it was > functionality and API that was part of the platform > - *exceptions* & *multipart* - needed by cgi - is exceptions now > subsumed by something in transformers? and... multipart? maybe time to drop > cgi? We didn't have it last time anyway as it wouldn't compile! > - *scientific* - needed by attoparsec - debated in detail last time > ... and we're still here! > > The Platform is significantly larger now: On OS X it has gone from 316M to > 499M! Most of this is due to new OpenGL libs which are now huge (went from > 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole > installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at > GitHub <https://github.com/haskell/haskell-platform/tree/pre-release>, > and the OS X builds are at my usual platform staging area: > > Index of /mark/platform <http://www.ozonehouse.com/mark/platform/> > > > Remember, it already includes GHC, so no need to download the GHC binary > for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! > > - Mark > >

10 16

Re: [Haskell-cafe] ListT considered harmful
by Chris Wong 27 Mar '15

27 Mar '15

On Fri, Mar 27, 2015 at 5:07 PM, Michael Snoyman <michael(a)snoyman.com> wrote: > I'm in favor of deprecation, but opposed to removing any time soon due to > backwards compatibility concerns. I agree. Given that we just deprecated ErrorT (which is both more popular, and does follow the monad laws) I think there is good reason to phase out transformers' ListT as well. I've attached a patch that adds the relevant pragma. I'm not familiar with darcs so excuse me if it's messed up :) libraries list and/or Ross Paterson, do you have anything to say about this issue? > On Fri, Mar 27, 2015 at 7:03 AM Fumiaki Kinoshita <fumiexcel(a)gmail.com> > wrote: >> >> It is well known that ListT m in transformers is not a monad unless the >> underlying monad is commutative. The fact that ListT is not a monad >> transformer is sufficient to remove it from the package, and several >> packages already defined their own ListT. >> >> Oughtn't we deprecate ListT or replace it by a correct one? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong https://lambda.xyz

1 0