- Libraries - Haskell.org

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

30 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 30 Mar '15

30 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 30 Mar '15

30 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 29 Mar '15

29 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

ansi-wl-pprint
by Edward Kmett 26 Mar '15

26 Mar '15

ansi-wl-pprint sits underneath a large chunk of our infrastructure: test-framework, criterion, trifecta, etc. Transitively through those dependencies it affects a very large percentage of the Haskell packages we have today, because you can't build almost anybody's testing and benchmarking frameworks without it. We recently had to push out an non-maintainer update for GHC 7.10-rc3 compatibility, and due to NMU update guidelines meant we had to wait 2 weeks before we could do anything. This pretty much ensured that the entire 7.10-rc3 release cycle went by with very very few people able to run their test suites, and little testing was able to be performed in the allotted window. Fortunately, Neil managed to find a rather large regression on his own during this time: http://neilmitchell.blogspot.com/2015/03/finding-ghc-bug.html That said, given that we found issues with linear caused by the changes to Typeable, once we fixed the test suite, this gives me pause. I'm pretty sure nobody downstream of linear tried to run their test suites on rc3. I'd like to not find ourselves in that situation again. We have a policy of considering requests for maintainership transfer after ~6 months of inactivity. Max has been inactive for over a year. I'd like to invoke that today, and formally request to take over maintainership of ansi-wl-pprint. All of the visible activity on https://github.com/batterseapower in the last year or so is on java projects. We've already adopted test-framework. In the event Max returns to active status in the Haskell community, I'd happily relinquish control. Thank you for your consideration, -Edward

4 4

quick report using GHC 7.10 RC3
by Mark Lentczner 26 Mar '15

26 Mar '15

I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... — Mark

3 2

Generalize filterM to Applicative
by David Feuer 25 Mar '15

25 Mar '15

Currently, filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM p = foldr go (return []) where go x r = do flg <- p x ys <- r return (if flg then x:ys else ys) We could change this to filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] filterM p = foldr go (pure []) where go x r = f <$> p x <*> r where f flg ys = if flg then x:ys else ys

7 12