April 2015 - Libraries

Proposal for a generic showIntAtBase
by Vikas Menon 07 Apr '15

07 Apr '15

Hi, The current implementation of showIntAtBase in Numeric is limited to Chars currently. *showIntAtBase* * :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* The 2 reasons for this constraint is: a) We only accept functions of the form (Int -> Char) b) An implicit concatenation using (:) I'd like to propose a new function showIntAtBaseGeneric that removes the (Int -> Char) function constraint and takes an additional function to replace the implicit (:) operator. *showIntAtBaseGeneric* * :: (Integral a1, Num b, Show a1) =>* * a1 -> (b -> a) -> (a -> s -> s) -> a1 -> s -> s* Now showIntAtBase may be implemented as: *showIntAtBase :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* *showIntAtBase base toChr n0 r0 = showIntAtBaseGeneric base toChr (:) n0 r0* The API and behavior of showIntAtBase remains unchanged while allowing for generic conversions not limited to Chars alone. *Example: * *λ> showIntAtBaseGeneric 26 id (:) 500 [] -- convert 500 to base26 and provide output as a list.* *[19,6]* Please let me know thoughts/concerns if any to this proposal. Cheers, Vikas

5 8

ANN: logfloat 0.13.3
by wren romano 07 Apr '15

07 Apr '15

-------------------------------------------- -- logfloat 0.13.3 -------------------------------------------- This package provides a type for storing numbers in the log-domain, primarily useful for preventing underflow when multiplying many probabilities as in HMMs and other probabilistic models. The package also provides modules for dealing with floating numbers correctly. This version drops support for Hugs and GHC < 7.8. Nothing major has changed, so they should still work; it's just that they're no longer officially supported. Thus, this version of the library provides a transitional point between backwards compatability and adding new features (see below). -------------------------------------------- -- Changes since 0.12.1 (2010-03-19) -------------------------------------------- * Monomorphized logFloat, logToLogFloat, fromLogFloat, and logFromLogFloat: that is, they all take/return Double now. The change was made to help reduce the need for explicit type signatures. It shouldn't really affect most users, since it seems noone was really making use of the polymorphism provided by previous versions. To get the previous behavior back, just explicitly add calls to realToFrac wherever necessary. * Fixed some instances to get them to compile under the new role-based type system of GHC 7.10 * Cleaned up various extraneous rewrite rules, specializations, etc * Added the functions sum, product, and pow. Both sum and product preserve more precision than the fold-based definitions in the Prelude. Moreover, sum is _much_ faster than the Prelude version, since it only requires crossing the log/exp boundary n+1 times, instead of 2*(n-1) times. The only downside is that sum requires two passes over the input and thus is not amenable to list fusion. -------------------------------------------- -- Upcoming changes (0.14+) -------------------------------------------- * Since the Data.Number.RealToFrac module is no longer required by any of the others, it will probably be forked off to a separate package in order to improve portability of the rest of the package by removing the need for MPTCs. * There's long been clamoring for adding a vector:Data.Vector.Unboxed.Unbox instance. I've been reluctant to add such an instance due to wanting to retain backwards compatibility and portability. Having dropped support for Hugs and older versions of GHC, I'm now willing to add them in. The logfloat library is conceptually quite simple, and thus to whatever extent possible I'd still like to retain portability to non-GHC compilers. So if you are interested in using logfloat with another compiler/interpreter but run into problems (e.g., due to the type families required by the vector library), please get in touch and I'll try to get things to work. -------------------------------------------- -- Compatibility / Portability -------------------------------------------- The package is compatible with GHC 7.8.3 and 7.10.1. It may still compile with older versions of GHC (or even Hugs!), however they are no longer officially supported. The package is not compatible with nhc98 and Yhc because Data.Number.RealToFrac uses MPTCs. However, that module is no longer required by any others, and all the other modules should be compatible with these compilers. Thus, it should be fairly easy to port. If you do so, please let me know and I'll try to incorporate support for them. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat/ Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren

2 3

A Random Strawman
by Dominic Steinitz 06 Apr '15

06 Apr '15

Hello All, Having skimmed the literature, run some tests and benchmarks: The current System.Random is broken: https://github.com/haskell/random/issues/25#issuecomment-87423142. Furthermore, this is recorded in at least two published papers: http://dl.acm.org/citation.cfm?id=2660195 and http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf. The tf-random package does not have this breakage and is based on good theoretical foundations. In my tests tf-random performs better than System.Random. As a result of which, I am very much inclined to suggest we replace the code in System.Random with tf-random. Before doing any more work on this, I’d like to understand what the next steps should be. How much review should be carried out? I have no reason to doubt the implementors have done a great job but should someone (who?) review the code more formally. If so what would the process / tools be? Tests in packages / applications may now fail as the (pseudo) random numbers will be different with this change. What should we do here? Alert folks (who and how?) that the may have to rebase their tests? Tell folks that 1.1 is deprecated and they should move to 2.0 (I think it’s right to indicate this is a completely new version)? Are there any other steps? FYI: I did look at Guy Steele et al. but I don’t believe there is currently a Haskell implementation of it, probably ruling it out as possible solution in the medium term. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

3 3

Stable location for monomorphic foldr?
by Joachim Breitner 02 Apr '15

02 Apr '15

Hi, I just stumbled over a FTP breakage: A RULES with "foldr" on the left hand side would no longer fire, because it would refer to Foldable.foldr, and not the monomorphic foldr. Adding #if MIN_VERSION_base(4,8,0) import Prelude hiding (foldr) import GHC.OldList (foldr) #endif to the file solved the problem for now, but GHC.OldList is supposed to go away eventually, so I believe we need a permanent location for the monomorphic foldr. Or will we simply not get rid of GHC.OldList at all? (One could argue that "foldr" on the left-hand-side of a RULE should work and that this is a GHC bug, though.) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

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

3 2