July 2015 - Libraries

‘temporary’ takeover
by Mateusz Kowalczyk 23 Jul '15

23 Jul '15

Hi, I'm looking to take over the ‘temporary’ package. This is to address the issue of any patches/fixes into ‘temporary’ not being merged in a timely manner[1]. This caused Roman Cheplyaka to create a fork package, ‘temporary-rc’. It's less than ideal to have some packages use temporary and others use temporary-rc (PackageImports needed…) so this is in attempt to bring back temporary as the one true package to use here and let the fork fall into obscurity, preferably deprecated. The main user of temporary-rc is the popular tasty package which is Roman's. If me/him/us both/someone (reliable/available) can take over temporary, he seems to be willing to go back to using that instead of the fork[2]. CCing the current maintainer. I think until Monday (27th) is a fair notice though I point out more time elapsed on [1] without a reply. [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html [2]: https://github.com/feuerbach/temporary/issues/1 -- Mateusz K.

6 6

Re: Proposal: instance MonadIO Q
by Ryan Scott 23 Jul '15

23 Jul '15

> Why would you make it depend on template haskell rather than the other way around? No particular reason, I'd be fine putting the instance in template-haskell instead if that's more palatable.

2 1

ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
by Ivan Lazar Miljenovic 22 Jul '15

22 Jul '15

I'm pleased to announce that I've (finally!) just released version 5.5.2.0 of [fgl]. Major changes in this release include a test suite, refactorings, code clean-ups and the following potentially breaking changes (in that they were previously unspecified or incorrect): - `nodeRange` and `nodeRangeM` for the various graph data structures erroneously returned `(0,0)` for empty graphs (making them indistinguishable from graphs containing the single node `0`). They now match the default implementation of throwing an error. - The behaviour of `delLEdge` when dealing with multiple edges was unspecified; it now deletes only a single edge and the new function `delAllLEdge` deletes all edges matching the one provided. All changes can be found in the changelog. [fgl]: https://hackage.haskell.org/package/fgl Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e. the "I finally build against the version on Hackage" release). [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

3 3

ANN: haddock-2.16.1
by Mateusz Kowalczyk 22 Jul '15

22 Jul '15

Hi, We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I inline the changelog at the bottom. It should work fine with 7.10.x GHC family. The packages are already on Hackage: haddock for the executable, haddock-api for the guts and use from Haskell and haddock-library which is the comment parser. It should also be shipping with GHC 7.10.2. I think two things are worth mentioning before: * The pending mathjax PR[1] is going to be included in future release of Haddock. As it is likely to break the interface file version, I am putting it off a bit to bundle with other possibly interface-breaking changes. * Our GSOC student has successfully completed first part of his project[2]. It involves native source code highlighting and perhaps more excitingly, source hyperlinking: you should now be able to click on identifiers to be taken to their definitions. This change is not in 2.16.1 as it is rather recent so we erred on the side of safety when picking what to release with GHC 7.10.2. You can try it by building current Haddock master, should work with 7.10.x family. As usual, if you want to contribute, please do so on GitHub. We're also on IRC under #haddock. Thanks! Changes in version 2.16.1 * Don't default to type constructors for out-of-scope names (#253 and #375) * Fix Hoogle display of constructors (#361) * Fully qualify names in Hoogle instances output (#263) * Output method documentation in Hoogle backend (#259) * Don't print instance safety information in Hoogle (#168) * Expand response files in arguments (#285) * Build the main executable with -threaded (#399) * Use SrcSpan of declarations for inferred type sigs (#207) * Fix cross-module instance locations (#383) * Fix alignment of Source link for instances in Firefox (#384) [1]: https://github.com/haskell/haddock/pull/397 [2]: https://github.com/haskell/haddock/pull/410 -- Mateusz K.

2 1

QuickCheck failures with new 'tar' release...
by Michael Alan Dorman 20 Jul '15

20 Jul '15

I'm not sure if there's a more appropriate venue to bring this up; the package doesn't seem to have any sort of explicit issue tracker. On the NixOS build servers, we're seeing across-the-board failures for the 0.4.2.0 release of the 'tar' library, specifically, two properties that were added in the latest release. It looks to me like prop_lookup is fundamentally broken---it falls over in the face of a lookup for 'a/b' in a list of entries that includes 'a/b/c/d', because while the library lookup function returns a match including the remainder of the path as a result, the Data.List.lookup that it's comparing against returns nothing. I don't see a way for the test as it is constituted to work reliably. I'm going to guess that prop_valid suffers from a similar issue. Either way, it would be nice if they could either be corrected, or diked out until that happens. Mike.

3 3

Proposal: instance Alternative ZipList
by Edward Kmett 20 Jul '15

20 Jul '15

The ZipList data type admits one legal Alternative instance instance Alternative ZipList where pure = ZipList [] ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys) The legality of this instance was first noted in http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf I propose adding this instance, which acts like a generalized version of the Alternative for Maybe, choosing with a left bias. Discussion Period: 2 weeks -Edward

4 5

Improving the "Get Haskell Experience"
by Mark Lentczner 19 Jul '15

19 Jul '15

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options. Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan: - Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users. - Use the *stack* model for package installation: - The global db has only the GHC packages - There is a package db for each curated set, Haskell Platform becomes one such set - Projects each have their own package db, much like sandboxes. - Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that *stack* can be used to build and install, on as needed, the corresponding Haskell Platform release packages. We think this plan solves many different community needs: - We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work. To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting *stack* ready such a distribution; and configuring (or updating) *cabal-install* to support the three-layer package db scheme. We think we can do this in short order. We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially *ghc*, *cabal*, and *stack*. We'd like to get your input. - Michael & Mark

9 13

Re: More general Generic and Data instances for Data.Proxy.Proxy?
by Ryan Scott 18 Jul '15

18 Jul '15

It does seem unnecessary. The Data instance for Proxy is manually written in Data.Data: proxyConstr :: ConstrproxyConstr = mkConstr proxyDataType "Proxy" [] PrefixproxyDataType :: DataTypeproxyDataType = mkDataType "Data.Proxy.Proxy" [proxyConstr] instance (Data t) => Data (Proxy t) where gfoldl _ z Proxy = z Proxy toConstr Proxy = proxyConstr gunfold _ z c = case constrIndex c of 1 -> z Proxy _ -> error "Data.Data.gunfold(Proxy)" dataTypeOf _ = proxyDataType dataCast1 f = gcast1 f If dataCast1 weren't defined to be gcast1, then that instance would only require a Typeable t constraint, which would make it polykinded. To be honest, I'm not sure why gcast1 requires a Data t constraint (I don't use Data that often, so hopefully someone more knowledgeable than me can answer this).

3 2

Re: More general Generic and Data instances for Data.Proxy.Proxy?
by Ryan Scott 18 Jul '15

18 Jul '15

Actually, Data.Data already has PolyKinds enabled, but the (Data t => Data (Proxy t)) instance requires that the type parameter be of kind *, since the Data typeclass has kind * -> Constraint. On the other hand, switching on PolyKinds in GHC.Generics should provide a polykinded Generic (Proxy t) instance (the corresponding instance in the tagged library is already polykinded, in fact). If we enable PolyKinds in GHC.Generics, we could also make Rep, Generic1, Rep1, V1, U1, Rec1, K1, M1, (:+:), (:*:), and (:.:) polykinded.

2 1

More general Generic and Data instances for Data.Proxy.Proxy?
by Carl Howells 17 Jul '15

17 Jul '15

At the moment, the following two instances are listed in the haddocks for Data.Proxy.Proxy: Data t => Data (Proxy * t) Generic (Proxy * t) Do those instances need to be that restrictive? Would it be possible to generalize those instances to these? Data (Proxy k t) Generic (Proxy k t) I'm not 100% comfortable with either of those classes, so I'm not sure if those instances work right, but it seems like they should in a hand-wavy way. -- Carl Howells

2 1