- Haskell-Cafe - Haskell.org

Generalizing "unlift" functions with monad-control
by Michael Snoyman 05 Apr '15

05 Apr '15

I'm trying to extract an "unlift" function from monad-control, which would allow stripping off a layer of a transformer stack in some cases. It's easy to see that this works well for ReaderT, e.g.: {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} import Control.Monad.Trans.Control import Control.Monad.Trans.Reader newtype Unlift t = Unlift { unlift :: forall n b. Monad n => t n b -> n b } askRun :: Monad m => ReaderT r m (Unlift (ReaderT r)) askRun = liftWith (return . Unlift) The reason this works is that the `StT` associated type for `ReaderT` just returns the original type, i.e. `type instance StT (ReaderT r) m a = a`. In theory, we should be able to generalize `askRun` to any transformer for which that applies. However, I can't figure out any way to express that generalized type signature in a way that GHC accepts it. It seems like the following should do the trick: askRunG :: ( MonadTransControl t , Monad m , b ~ StT t b ) => t m (Unlift t) askRunG = liftWith (return . Unlift) However, I get the following error message when trying this: foo.hs:11:12: Occurs check: cannot construct the infinite type: b0 ~ StT t b0 The type variable ‘b0’ is ambiguous In the ambiguity check for the type signature for ‘askRunG’: askRunG :: forall (t :: (* -> *) -> * -> *) (m :: * -> *) b. (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘askRunG’: askRunG :: (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) Adding AllowAmbiguousTypes to the mix provides: foo.hs:17:30: Could not deduce (b1 ~ StT t b1) from the context (MonadTransControl t, Monad m, b ~ StT t b) bound by the type signature for askRunG :: (MonadTransControl t, Monad m, b ~ StT t b) => t m (Unlift t) at foo.hs:(12,12)-(16,25) ‘b1’ is a rigid type variable bound by the type forall (n1 :: * -> *) b2. Monad n1 => t n1 b2 -> n1 (StT t b2) at foo.hs:1:1 Expected type: Run t -> Unlift t Actual type: (forall (n :: * -> *) b. Monad n => t n b -> n b) -> Unlift t Relevant bindings include askRunG :: t m (Unlift t) (bound at foo.hs:17:1) In the second argument of ‘(.)’, namely ‘Unlift’ In the first argument of ‘liftWith’, namely ‘(return . Unlift)’ I've tested with both GHC 7.8.4 and 7.10.1. Any suggestions?

3 7

Is it possible for cabal sandboxes to use $HOME/.cabal/lib?
by Aldo Davide 05 Apr '15

05 Apr '15

Hi all, There are some packages that I use again and again and I would like to install them once (but not in a system-wide location) and then have cabal sandboxes use that install, instead of installing them in every sandbox, which is time consuming. Is there a way do that? For example, I noticed that cabal, when operating inside a sandbox, can still find the packages installed system-wide, but not the ones in $HOME/.cabal/lib. Can I change that? Thanks

5 8

Help wanted: working on the GHC webpage
by Austin Seipp 03 Apr '15

03 Apr '15

Hello *, For a while now, I've been wanting to do a facelift on the GHC homepage, but among many other things it's been a low priority. I'd like for people to help, so I've tried to get the ball rolling. The webpages existed in a Darcs repository previously (which wasn't available online), but earlier today I converted them to a git repository which you can find here: https://github.com/haskell-infra/ghc-homepage The site is currently composed of a set of "server side include" files that have a crude form of HTML templating. So it's mostly just pretty verbose to add or refactor anything, and the sites templating and styling is quite old (it dates back at least 10 years!) So, I'm making an official call for some help. At the very least, I'd like to at least end up converting the site to something like Hakyll which is doable without me causing a lot of damage to the stylesheets, but for the actual page itself I'd really appreciate it if anyone could help out! Please send pull requests or file issues, it's much appreciated. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Re: [Haskell-cafe] An Easy Solution to PVP Bounds and Cabal Hell
by Olaf Klinke 03 Apr '15

03 Apr '15

I am mostly a consumer of Haskell and have not worked much with the interior of cabal or GHC, but Thomas Tuegel correctly pointed out that with version numbers a package can never safely depend on another package version that was released after itself. The empirical approach of trying builds is probably the most inclusive one. But let us think why dependencies can break a package. It is because a function was removed from the namespace, conflicting things have been added to the namespace, a data type definition has changed or the modules have been re-structured. In the worst case, none of the above has happened but the semantics of a function has changed without affecting its type. But all other cases can be dealt with: When importing a module, either a smart compiler figures out or the programmer states explicitly which imported functions are expected to be provided by the imported module and what type they have. Thus, the version number of a package is replaced by the collection of classes, types and type signatures its modules export. After all, the version number can be seen as a crude „hash“ of this information. For example, instead of stating import Data.List (mapAccumL) on would say import Data.List (mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])) or rather the compiler would fill in this information and save it together with the package as a dependency. Now when a new version of Data.List comes out, it can be automatically checked whether all functions _used_ by the importing module are still exported and have the same type signature. Modulo semantics, this should be a pretty good estimate of whether a build will fail or succeed. One could possibly even add QuickCheck properties to the signatures stating that the imported functions are expected to behave in a certain way in the importing module. When installing the new package on a system, all these assertions need to be checked. Isn’t that what configure scripts do prior to executing a makefile? Olaf

1 0

Haskell-programming sysadmin opportunity at SFLC
by Clint Adams 03 Apr '15

03 Apr '15

The Software Freedom Law Center is seeking a motivated systems administrator for our small office, where we use only free and open source software. The Systems Administrator will be responsible for three main areas of work: systems maintenance, user support, and systems development. Our existing systems are a collection of Debian servers that provide central services to the office. In addition to Debian, we use: - Apache - Asterisk - Ceph - deets - dirvish and BoxBackup - Ganeti with Xen and KVM - Gitolite - Hakyll - hledger and hledger-web - Ikiwiki - Monkeysphere - Nginx - OpenLDAP - OpenVPN - Postfix/SpamAssassin/Dovecot - Radicale - Yesod as well as a number of other systems. Ideal candidates will have experience with most of these components and the ability to quickly master the ones they know less about. As our new Systems Administrator, you will be responsible for maintaining and rebuilding our servers as necessary so some knowledge of server components and hardware configuration will be needed. You should have experience with firewall management and secure network design. Experience with low-latency bandwidth shaping preferred. Programming experience with Perl, Python, Haskell, and shell scripts will also be necessary for maintaining legacy systems. In addition to the servers, you will also be responsible for supporting 5—10 desktop users with their daily use of free software. Additional help with this activity is available around the office and many users are self-supporting for local system issues. All office user machines are running Debian. You will be frequently tasked with other functions, which may include code analysis, explaining technological concepts and licensing to lawyers, community outreach, and anything else which may require technical expertise. We intend to continue to improve our free software technology for running our law practice. There are many challenging projects we’d like to do and about which we hope you will be excited. Experience working with software development in addition to systems administration is therefore a big plus. Position includes full benefits. Please submit a cover letter and resume in a free document format to officemanager(a)softwarefreedom.org Applications should be submitted no later than April 15, 2015

1 0

cabal haddock --executables
by Maurizio Vitale 02 Apr '15

02 Apr '15

I'm getting: cabal: internal error when calculating transitive package dependencies. Debug info: [] and it seems this has been a problem for quite some while (and it has to do with the executable depending on a local library) is there any known workaround? Thanks, Maurizio

2 2

Announcing: LTS (Long Term Support) Haskell 2
by Michael Snoyman 02 Apr '15

02 Apr '15

The LTS Haskell 2.0 release is officially out the door. More details are available at: https://www.fpcomplete.com/blog/2015/04/announcing-lts-2 For the tl;dr crowd, run the following inside your project to get a cabal.config with appropriate constraints: wget https://www.stackage.org/lts/cabal.config There are some questions about policy at the end of the post that I'd appreciate feedback on.

1 0

Parallel Profiling
by Dominic Steinitz 02 Apr '15

02 Apr '15

Does anyone know of any tools for analysing parallel program performance? I am trying to use threadscope but it keeps crashing with my 100M log file and ghc-events-analyze is not going to help as I have many hundreds of threads all carrying out the same computation. I think I’d like a library that would allow me to construct my own analyses rather than display them via GTK. There is ghc-events but that seems to be just for parsing the logs and I couldn’t find anything that used it in the way I would like to (apart from threadscope and ghc-events-analyze of course). Thanks Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 2

Haskell Weekly News
by Kim-Ee Yeoh 02 Apr '15

02 Apr '15

*Top picks:* - Bot attack on Trac <https://mail.haskell.org/pipermail/ghc-devs/2015-March/008557.html> pummels GHC HQ productivity! Do you know a thing or two about hardening web apps? Can you help? - A month ago <http://haskell.1045720.n5.nabble.com/Haskell-Weekly-News-td5766529.html> you read about the absence of a correct operational spec for Core. Christiaan Baaij <http://ghc.haskell.org/trac/ghc/ticket/10121#comment:7> proffers rewriting rules for something "very much like Core" from his 2014 thesis on Digital Circuits in CλaSH, a tool designed for Computer Architecture for Embedded Systems (CAES). The consensus is that they probably also work for GHC Core. - Neil Mitchell reports Unable to load package Win32-2.3.1.0 <https://ghc.haskell.org/trac/ghc/ticket/10165>. The problem? SetWindowLongPtrW exists only on 64-bit. The haskell win32 shim wasn't switching to SetWindowLongW on 32-bit. Darren Grant steps up to offer a fix, which Austin Seipp promptly checks in. - Ki Yung Ahn <http://haskell.1045720.n5.nabble.com/Do-we-have-idiom-for-lifting-a-state-m…> asks for a "wrapper that lifts actions of (State s1 a) to (State (s1,s2) a). " The answer? A function called "zoom" in lens libraries. - Chris Done <https://groups.google.com/forum/#!msg/commercialhaskell/lRTDiTLIKi0/Kw0UGwa…> has started the ball rolling on GPG-based package signing. So far, Michael Snoyman and Neil Mitchell have had their keys signed by Chris. He invites others to join the party. - Levant Erkok <https://ghc.haskell.org/trac/ghc/ticket/10215> joins Lennart Augustsson <https://ghc.haskell.org/trac/ghc/ticket/9238> in hitting a bug with signed zeros <http://en.wikipedia.org/wiki/Signed_zero>. The function isNegativeZero breaks under optimizations. - James Stevenson <https://blog.safaribooksonline.com/2015/03/30/high-performance-log-parsing-…> over at Safari Books Online reveals how they use Haskell to parse web logs more efficiently than Python. The top comment <https://news.ycombinator.com/item?id=9294036> at Hacker News observes the absence of a proper benchmark pitting Python vs Haskell. James responds that they did an informal comparison that showed "the number of lines parsed/second [with Python] was far smaller than the attoparsec-based parser." Elsewhere, Luke Randall <http://www.reddit.com/r/haskell/comments/30xugp/highperformance_log_parsing…> submits the link on reddit and thinks it's a "very gentle intro to parsing using attoparsec". - Ian Ross <http://www.skybluetrades.net/blog/posts/2015/03/30/c2hs-snowmelt.html> announces a new C2HS release christened "Snowmelt". Originally authored by Manuel Chakravarty, C2HS eases the pain of manually creating FFI shims for C libraries. The latest release, thanks to work contributed by Philipp Balzarek, achieves better cross-language alignment of C enum and Haskell Enum types, among other improvements. Reddit discussion here. <http://www.reddit.com/r/haskell/comments/30u8pk/new_c2hs_release_0251_snowm…> - Michael Snoyman <https://www.fpcomplete.com/blog/2015/03/announce-ide-backend> announces FPComplete's open sourcing of their IDE backend, comprising a wrapper around the GHC API. - Jon Sterling at PivotCloud <https://ghc.haskell.org/trac/ghc/ticket/9539#comment:2> hits an STM TQueue bug initially reported by John Lato seven months ago. A sufficiently fast writer can cause the reader to never get scheduled, which leads to live-lock in Jon's production code. The fix looks to be as simple as lazifying a case into a let in readTQueue. Curiously, the code uses let in Simon Marlow's book on Haskell concurrency <http://chimera.labs.oreilly.com/books/1230000000929/ch10.html#CO37-2> but not in the STM package you have on your machine. *Tweets of the week:* - Michael Neale <https://twitter.com/michaelneale/status/567532684595851264>: Haskell Quickcheck enters a bar, asks for 1 beer, 42 beers, -Inifinity beers, shaves bartenders beard, sets off a tactical nuke. - Dierk König <https://twitter.com/mittie/status/582803534950862848>: #Haskell is the gold standard for programming languages and #Frege makes it available on the #JVM -- Kim-Ee

1 0

An Easy Solution to PVP Bounds and Cabal Hell
by Gershom B 01 Apr '15

01 Apr '15

Recently there has been some discussion about how we can fix the problem of “Cabal Hell”. Some people advocate restrictive upper bounds, to prevent packages from being broken by new updates. Some other people point out that too-restrictive bounds can lead to bad install plans, since some packages might want newer versions of some dependencies, and others older versions. Still other people say that we can _retroactively_ fix upper bounds (in either direction) by modifying cabal files using the new features in Hackage. Some people think this is a terrible idea because it looks like we are mutating things, and this confuses hashes. In turn, these people support either nix or a nix-like approach by which packages have hashes that encompass the full versions of all their transitive dependencies. With that in hand, we can cache builds and mix-and-match to build the precise environment we want for each package while reducing redundant computation. However, the cache of all the various binary combinations may still grow large! And none of this fully begins to address the dreaded “diamond dependency” problem. Here is a chart of some such solutions: http://www.well-typed.com/blog/aux/images/cabal-hell/cabal-hell-solutions.p… One way to look at a particular build is in an n-dimensional state space (of the Hilbert sort) determined by all its dependencies, not least the compiler itself. The solver acts as a particle traversing this space. But this description is too simple. Our state of dependencies and constraints itself varies and grows over time. So another approach is to think of the dependencies as a transitive graph, where each node may vary along a time axis, and as they slide along the axis, this in turn affects their children. We now have not just one Hilbert space, but a collection of them related by branching trees as authors locally modify the dependencies of their packages. If we keep this simple model in mind, it is easy to see why everyone is always having these debates. Some people want to fix the graph, and others want to simplify it. Some people want an immutable store, and some people want to rebase. But we can’t “really” rebase in our current model. Bearing in mind our model of a space-time continuum of hackage dependences, the solution emerges — enforce immutability, but allow retroactive mutation. For instance, suppose Fred tries to install package Foo on Friday evening, but discovers that it depends on version 1.0 of Bar (released the previous Friday) that in turn depends on version 0.5 of Baz but Foo also depends on version 0.8 of Baz. So Fred branches Bar and changes the dependency, which in turn informs Betty, that there is also a 1.0 of Bar with different dependencies and we have forked our package timeline. On getting this message on Monday, Betty can merge by pushing with --force-rewrites and this goes back in the timeline and makes it so that Baz retroactively had the right dependencies and now Fred, as of the previous Friday, no longer has this problem. (That way he still has the weekend). Now the failed build is cut off temporarily into a cycle in the package timeline that is disconnected from the rewrite. We stash it with “hackage stash” until Monday at which time the dependency graph is 100 percent equalized and primed for new patches. At this point we unstash Foo as of Friday and it is replaced by the Foo from the new timeline. Friday Fred needs to remain stashed lest he run into himself. The longer he can be avoided by his Monday self the better. Future work could include bots which automate pruning of artifacts from redundant branches. If this description was too abrupt, here is a diagram with a fuller description of the workflow: http://bit.ly/15IIGac I know there are some new ideas to take in here, and there is a little technical work necessary to make it feasible, but in my opinion if you can understand the current cabal situation, and you can understand how git and darcs work, then you should be able to understand this too. Hopefully by this time next year, we’ll be able to say that our problems with cabal have been truly wiped from our collective memory. HTH, HAND. Gershom

4 3