News aggregator

How can I install a second version of GHC?

Haskell on Reddit - Mon, 05/12/2014 - 9:59am

I'm currently using Fedora 19 and have GHC 7.4 installed from the system package manager. I'd like to also install GHC 7.8 and was wondering what the best way to go about installing it was such that my current working GHC wasn't affected.

submitted by vamega
[link] [11 comments]
Categories: Incoming News

Philip Wadler: The EFF, Oracle, Google, and me: A Dangerous Decision

Planet Haskell - Mon, 05/12/2014 - 6:42am
Previously, I wrote of an amicus brief filed by the EFF in a case between Oracle and Google, of which I am a co-signatory. The decision is out, and it is worrying.
When programmers can freely reimplement or reverse engineer an API without the need to negotiate a costly license or risk a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to create. Moreover, compatible APIs enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. The freedom to reimplement APIs also helps rescue “orphan” software or data—systems whose creators have either gone out of business or abandoned their product in the marketplace. Today's decision puts all of that at risk, potentially handing Oracle and others veto power over any developer who wants to create a compatible program. What is worse, if today's decision is taken as a green light to API litigation, large and small software tech companies are going to have to divert more and more resources away from development, and toward litigation. That will be good for the legal profession—but not so good for everyone else. The case is far from over. Google may seek a hearing from the full court, or appeal to the Supreme Court. Alternatively, Google can focus on asserting its fair use defense, and hope that fair use can once again bear the increasing burden of ensuring that copyright spurs, rather than impedes, innovation.  We're confident that it can, but it shouldn't have to.
Categories: Offsite Blogs

Skills Matter - Mon, 05/12/2014 - 4:14am
Categories: Offsite Blogs

Is there a name for defining recursive functions as infinite lists of input/output pairs by zipping two inductive datatypes?

Haskell on Reddit - Mon, 05/12/2014 - 2:14am

Recursive functions are usually defined by directly calling a function inside its own body.

Nat = Z | S Nat double Z = Z double (S x) = S (S (double x)))

What if, instead of defining them this way, we just enumerated two recursive datatypes and zipped them?

To be more descriptive, mind the following functions:

enum Nat = [Z, S Z, S S Z, S S S Z ...] # a b = \x -> (zip (enum a) (enum b)) !! (elem x (enum a))

That is, enum enumerates elements of a recursive datatype. Now, using #, there is an interesting way to define some recursive functions.

Even = Z | S (S Even) double = Nat # Even

This makes double equivalent to:

double x = [(0,0),(1,2),(2,4),(3,6)...] !! x

In other words, instead of defining the function recursively, we just created an infinite list with the input/output pairs of that function, by zipping two recursive datatypes together. I never heard of this approach being used, so my question is: this there a name for this? Any relevant papers? What kinds of functions can be defined this way?

submitted by SrPeixinho
[link] [3 comments]
Categories: Incoming News

FP Complete: GHC 7.8, transformers 0.3, and lenient lower bounds

Planet Haskell - Mon, 05/12/2014 - 2:00am

In the Stackage maintainer's agreement, there's a section about keeping your package compatible with the newest versions of all dependencies. What the maintainer's agreement doesn't (yet) discuss is when it's important to be compatible with old versions of a package. The reasons for this are not immediately obvious, especially as it affects a smaller subset of the Hackage author population. This blog post will cover some of the reasons for this goal.

The original impetus for writing this was to get one specific message across: please continue supporting transformers-! For the explanation of why, please keep reading.

Non-upgradeable packages

The simplest case to discuss is packages like base and template-haskell. Not only are these packages shipped with GHC, but they cannot be upgraded. As a result, if you have a package that says base >= 4.7, it will only work with GHC 7.8 and later. Users who are still using 7.6 (or 7.4... or earlier... yes, those people do in fact exist) will have no means of using your package.

That of course brings up a question of how many versions of GHC you want to support. I'd highly recommend always supporting the most recent Haskell Platform release, as many users (especially Windows users) stick to that. Going back an extra version as well isn't a bad idea either, especially as some distributions (e.g., Ubuntu) tend to ship relatively old GHC versions.

Upgradeable, GHC-shipped packages

This issue is more subtle. In addition to non-upgradeable packages, GHC includes a number of packages which can be installed separately, resulting in one copy of the package in your global database, and one in your user database. (Yes, you can also install into the global database, but I'm covering the common case here.) Examples of these packages are bytestring, binary, and containers.

The first problem with this is that it can lead to end-user confusion. How many of you have tried working in GHCi, or just compiling code with ghc --make, and gotten a message along the lines of "Could not match type ByteString with ByteString"? That usually comes from two versions of a package being available.

Now that's just a bit of an annoyance, and building your code with cabal will almost always avoid it. But there's a second, more serious problem. Some of these upgradeable packages are in turn depended upon by non-upgradeable packages. For example, template-haskell depends on containers. As a result, imagine if you try to use containers 0.5 and template-haskell when on GHC 7.4. Since template-haskell depends on containers-, you'll run into issues.

Another problem is the ghc package (aka GHC-the-library). With GHC 7.8.2, I have the following dependencies for the installed ghc package:

depends: Cabal- array- base- bin-package-db- bytestring- containers- directory- filepath- hoopl- hpc- process- template-haskell- time-1.4.2-b47642c633af921325b5eb4d5824b9de transformers- unix-

So if I try to use- for example- transformers and a package requiring ghc at the same time, I'll run into a conflict. And there are actually a large number of such packages; just doctest has over 100 dependencies.

Haskell Platform

The last reason is the one I hear the most pushback about from package authors. The Haskell Platform pegs users at specific versions of dependencies. For example, the most recent HP release pegs text at Now imagine that you write a package that depends on text >= 1.0. A user with the Haskell Platform installed will likely get warnings from cabal when installing your package about conflicting versions of text, and possibly breaking other packages that depend on it.

I can tell you what I've personally done about this situation. For my open source packages, I make sure to keep compatibility with the Haskell Platform released version of a package. Sometimes this does lead to some ugliness. Two examples are:

  • streaming-commons has to have a copy of some of the streaming text code, since it was not available before text 1.1. (And due to an issue with cabal, we can't even conditionally include the code.)
  • In chunked-data, I wasn't able to rely upon the hGetChunk function, and instead needed to use CPP to include a far less efficient backup approach when using older versions of text.

In the Stackage project, I run versions of the build both with and without Haskell Platform constraints. There are actually a whole slew of conditionals in the version selection which say "if you're using HP, then use this older version of a dependency." However, as time goes on, more and more packages are simply not supporting the HP-pegged versions of packages anymore.

Future changes

I'm not commenting here on the value of HP-pegged versions, but simply pointing out a reality: if you want your users to have a good experience, especially Windows users, it's probably a good idea to keep compatibility with the older HP-provided versions. I also think the ramifications of the HP approach really need to be discussed by the community, it seems like there's not much discussion going on about the impact of the HP.

Also, regarding the packages shipped with GHC: there have certainly been discussions about improving this situation. I know that removing the Cabal dependency from ghc has been discussed, and would certainly improve the situation somewhat. If others want to kick off a conversation on improving things, I'd be happy to participate, but I frankly don't have any concrete ideas on how to make things better right now.

Categories: Offsite Blogs

Error when trying to use Hashable

haskell-cafe - Mon, 05/12/2014 - 1:58am
Hi Haskell Cafe, I have some code that compiles when running on GHC on OS X, but not on Ubuntu: No instance for (hashable- (GHC.Generics.Rep Point)) arising from a use of `hashable-$gdmhashWithSalt' Possible fix: add an instance declaration for (hashable- (GHC.Generics.Rep Point)) In the expression: (hashable-$gdmhashWithSalt) In an equation for `hashWithSalt': hashWithSalt = (hashable-$gdmhashWithSalt) In the instance declaration for `Hashable Point' Anyone know what's happening here? Cheers, -John
Categories: Offsite Discussion

Installation of package text failing installation onghc 7.6.3

haskell-cafe - Sun, 05/11/2014 - 9:46pm
I just downloaded the latest Haskell platform (I realize that ghc might not be up-to-date in this) for my macbook. I installed it, which appeared to go without problems. However, when I tried to update the package text, I get the errors below. I suspect that the first error (not recognizing ' in a comment) cascades through the rest. How do you suggest fixing this (other than getting Bryan do drop the apostrophe :-))? Victor Configuring text- Building text- Preprocessing library text- Data/Text.hs:9:52: warning: missing terminating ' character [-Winvalid-pp-token]
Categories: Offsite Discussion

ANNOUNCE: jhc-0.8.1

General haskell list - Sun, 05/11/2014 - 9:20pm
After a hiatus, jhc 0.8.1 is released. - New license, jhc is now released under a permissive BSD style licence rather than the GPL. The license is compatible with that of ghc allowing code mixing between them. - New library layout based around the standards, there are now haskell98 and haskell2010 packages that are guarenteed to be future proof strictly compatible with the respective standards. A package haskell-extras contains the additonal libraries from ghc's base. - Native support for complex and vector SIMD primitives, exposed via type functions. for instance 'foo :: Complex_ Float32_' for hardware accelerated complex 32 bit floats for instance. These are unboxed only for now, full library Num support in the works. - support for android as a target, you must install the android NDK to use this. - Support for embedded ARM architectures imported from Kiwamu Okabe's branch allowing targeting bare hardware with no OS. - user defined kinds, introduced
Categories: Incoming News

cabal install lens fails

haskell-cafe - Sun, 05/11/2014 - 3:29pm
Hi Haskell Cafe, Anyone know about this error? Installing library in /Users/johnky/Library/Haskell/ghc-7.6.3/lib/reflection-1.4/lib Registering reflection-1.4... Installed reflection-1.4 Configuring mtl- Building mtl- Preprocessing library mtl- [ 1 of 21] Compiling Control.Monad.Writer.Class ( Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o ) [ 2 of 21] Compiling Control.Monad.State.Class ( Control/Monad/State/Class.hs, dist/build/Control/Monad/State/Class.o ) [ 3 of 21] Compiling Control.Monad.Reader.Class ( Control/Monad/Reader/Class.hs, dist/build/Control/Monad/Reader/Class.o ) [ 4 of 21] Compiling Control.Monad.RWS.Class ( Control/Monad/RWS/Class.hs, dist/build/Control/Monad/RWS/Class.o ) [ 5 of 21] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs, dist/build/Control/Monad/Identity.o ) [ 6 of 21] Compiling Control.Monad.Error.Class ( Control/Monad/Error/Class.hs, dist/build/Control/Monad/Error/Class.o ) Control/Monad/Error/Class.hs:93:18
Categories: Offsite Discussion

Using mutable array after an unsafeFreezeArray, and GC details

glasgow-user - Fri, 05/09/2014 - 7:21pm
A couple of updates: Edward Yang responded here, confirming the sort of track I was thinking on: And I can report that: 1) cloning a frozen array doesn't provide the benefits of creating a new array and freezing 2) and anyway, I'm seeing some segfaults when cloning, freezing, reading then writing in my library I'd love to learn if there are any other approaches I might take, e.g. maybe with my own CMM primop variants? Thanks, Brandon
Categories: Offsite Discussion

Using mutable array after an unsafeFreezeArray, and GC details

glasgow-user - Fri, 05/09/2014 - 12:18am
I have an unusual application with some unusual performance problems and I'm trying to understand how I might use unsafeFreezeArray to help me, as well as understand in detail what's going on with boxed mutable arrays and GC. I'm using the interface from 'primitive' below. First some basic questions, then a bit more background 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a 2) And what if a do a `cloneMutableArray` on `a` and likewise use the resulting array? Background: I've been looking into an issue [1] in a library in which as more mutable arrays are allocated, GC dominates (I think I verified this?) and all code gets slower in proportion to the number of mutable arrays that are hanging around. I've been trying to understand how this is working internally. I don't quite understand how the "remembered set" works with respect to MutableArray. As best I understand: the remembered set in generation G points to certain objects in older generations, which objects hold references to ob
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!


Categories: Incoming News