News aggregator

Doctest, quickcheck and typeclass

haskell-cafe - Mon, 07/14/2014 - 5:39pm
Hi all, Is there a way, with doctest and quickcheck, to declare test at typeclass level (such as laws) and play them automatically at instance level? For example:
Categories: Offsite Discussion

Proposal: add -XPolyKinds to Data.Monoid

libraries list - Mon, 07/14/2014 - 5:37pm
At the moment, the Monoid instance for Data.Proxy.Proxy is only defined for types with kind *. Prelude Data.Proxy Data.Monoid> (Proxy :: Proxy String) <> Proxy Proxy Prelude Data.Proxy Data.Monoid> :set -XDataKinds Prelude Data.Proxy Data.Monoid> (Proxy :: Proxy 5) <> Proxy <interactive>:8:20: No instance for (Monoid (Proxy 5)) arising from a use of ‘<>’ In the expression: (Proxy :: Proxy 5) <> Proxy In an equation for ‘it’: it = (Proxy :: Proxy 5) <> Proxy Enabling -XPolyKinds while compiling the Data.Monoid module is the only change necessary to make the Monoid instance for Proxy polykinded like Proxy itself is. I don't believe adding a language pragma would have any other effect on that module, and I believe the only effect of changing that instance would be allowing more correct programs to compile. This is my first proposal to this list, so I'm starting with something that I hope isn't controversial. Let me know if I should do anything different pr
Categories: Offsite Discussion

How to walk under binders "for free" in 'bound'?

haskell-cafe - Mon, 07/14/2014 - 4:51pm
Dear list, I'm trying to implement a small dependently typed language (based on [1]) using the generalised De Bruijn indices from the 'bound' library [2]. My main two datatypes are: Representing my two types of binders, and: Representing terms. My problem lies with implementing type-inference for lambda-binders. Originally I started with: Where `toScope . inferType1 ctx' . fromScope` entails doing three subsequent traversals: - `fromScope` traverses the term in `s`, which quotients placements of 'F' distributing them to the leaves - `inferType ctx'` then traverses the result of `fromScope` to infer the type - `toScope` transforms the inferred type to a generalised De Bruijn form, requiring a full tree traversal. Also, the new context, `ctx'`, is defined in term of a traversal (fmap). Also note that, for every Scope I walk under, `ctx'` gets an additional traversal. Doing so many traversals seems/is expensive, so after some thinking I improved `inferType2` to: Where the only traversal needed to get
Categories: Offsite Discussion

ANN: HacBerlin - Haskell Hackathon in Berlin,26-28 Sep 2014

haskell-cafe - Mon, 07/14/2014 - 4:15pm
Dear Haskellers, another Haskell Hackathon is waiting for you! Where: Berlin, Germany When: Fri 26 - Sun 28 September 2014 Meet in Berlin, discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! For all details, visit our wiki page ( and make sure to register early. By the way: we are currently looking for one or two keynote talks. If you feel qualified, please let us know. Happy hacking, Stefan
Categories: Offsite Discussion

ANN: HacBerlin - Haskell Hackathon in Berlin,26-28 Sep 2014

General haskell list - Mon, 07/14/2014 - 4:15pm
Dear Haskellers, another Haskell Hackathon is waiting for you! Where: Berlin, Germany When: Fri 26 - Sun 28 September 2014 Meet in Berlin, discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! For all details, visit our wiki page ( and make sure to register early. By the way: we are currently looking for one or two keynote talks. If you feel qualified, please let us know. Happy hacking, Stefan
Categories: Incoming News

Call for participation: FOSDEM 2015

General haskell list - Mon, 07/14/2014 - 4:08pm
Hi all, I'm not a FOSDEM (maybe the biggest FOSS Developer meeting in Europe) organizer, but next year it will be the third time that I'll attend to it and I'd like to see a FP devroom. So, here is the CFP: If there are any good willings, don't wait! For the moment, if I understand well, they are looking for dev room coordinators, so: 1. If you want to give a talk, say it here, it will give an overview to potential coordinators 2. If you want to be coordinator, say it here, it will motivate talks proposals 3. If you want to be a half-time coordinator, say it, maybe an other one will do the same 4. If there are talks but no or not enough coordinator, I'll complete the team What ever what will happen, See you there, Regards. _______________________________________________ Haskell mailing list Haskell< at >
Categories: Incoming News

Call for Talk Proposals: Parsing< at >SLE

General haskell list - Mon, 07/14/2014 - 3:30pm
********************************************************************* CALL FOR TALK PROPOSALS Second Workshop on Parsing< at >SLE 2014 September 14, 2014 Västerås, Sweden Co-located with ASE, SLE, and GPCE ********************************************************************* Deadline for talk proposals: July 25, 2014 The goal of this workshop is to bring together today's experts in the fields of parser construction and parser application from across the diverse application areas. Participants will present ongoing work as well as explore the challenges that lie ahead. By bringing the whole community together (a rare occurrence, given the diversity of domain-specific conferences/workshops), we aim to forge new collaborations inspired by a wide-ranging collection of talks on parsing-related topics. *** Topics *** While parsing and parser generation, both in theory and in practice, are mature topics, there are challenging problems with respect to the construct
Categories: Incoming News

Roman Cheplyaka: Type-based lift

Planet Haskell - Mon, 07/14/2014 - 3:00pm

In mtl, the ask method of the MonadReader class will automatically «lift» itself to the topmost ReaderT layer in the stack, which is very convenient, but only works as long as the topmost layer is the one you need. If you have multiple ReaderTs in the stack, you often have to insert manual lifts.

Previously I described why a smarter automatic lifting mechanism is needed to build truly reusable pieces of monadic code without too much boilerplate.

In this article I show two ways to achieve a type-based lift (that is, a lift which takes into account the r of ReaderT r), one relying on IncoherentInstances, the other — on closed type families.

Class-based approach and IncoherentInstances

In Two failed attempts at extensible effects, I wrote that simply removing the fundep from mtl wouldn’t work. This claim was recently disproved by Ben Foppa and his extensible-transformers library.

Why did I think that such an approach wouldn’t work?

{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, OverlappingInstances #-} import Control.Monad.Trans.Reader hiding (ask) import qualified Control.Monad.Trans.Reader as Trans import Control.Monad.Trans.Class class MonadReader r m where ask :: m r instance Monad m => MonadReader r (ReaderT r m) where ask = Trans.ask instance (Monad m, MonadReader r m, MonadTrans t) => MonadReader r (t m) where ask = lift ask

GHC, when asked to compile something that uses the above instances, will ask you in return to enable the IncoherentInstances extension. My experience with GHC told me that such a request is just a polite way for GHC to say «You’re doing something wrong!», so I immediately dismissed that approach. I had never seen a case where IncoherentInstances would be an acceptable solution to the problem. Well, this one seems to be exactly such a case!

Switching IncoherentInstances on here not only makes the type checker happy, but also makes the code work as expected, at least in the few tests that I tried.

Closed type classes

Intuitively, the reason why GHC needs so many ugly extensions to make the above code work is that we’re trying to simulate a closed type class with an open one.

Our type class is essentially a type-level if operator comparing two types, and its two instances correspond to the two branches of the if operator.

If only we had closed type classes, we could write

import Control.Monad.Trans.Reader hiding (ask) import qualified Control.Monad.Trans.Reader as Trans import Control.Monad.Trans.Class class MonadReader r m where ask :: m r instance Monad m => MonadReader r (ReaderT r m) where ask = Trans.ask instance (Monad m, MonadReader r m, MonadTrans t) => MonadReader r (t m) where ask = lift ask

(where I put instance declarations inside the class declaration to show that the class is closed).

Alas, GHC 7.8 does not have closed type classes, and I have not even heard of them being developed. All we have is closed type families. Closed type families would let us compute, say, a type-level number showing how far we have to lift a monadic action to reach the right level. They, however, do not allow us to compute a value-level witness — the very lifting function!

Closed type families

Still, it is possible to achieve automatic lifting using closed type families alone. We developed this approach together with Andres Löh at ZuriHac’14.

The main idea is to split the problem into two.

First, we compute the amount of lifting required using a closed type family

-- Peano naturals, promoted to types by DataKinds data Nat = Zero | Suc Nat type family Find (t :: (* -> *) -> (* -> *)) (m :: * -> *) :: Nat where Find t (t m) = Zero Find t (p m) = Suc (Find t m)

Second, assuming we know how far to lift, we can compute the lifting function using an ordinary (open) MPTC:

class Monad m => MonadReaderN (n :: Nat) r m where askN :: Proxy n -> m r instance Monad m => MonadReaderN Zero r (ReaderT r m) where askN _ = Trans.ask instance (MonadTrans t, Monad (t m), MonadReaderN n r m, Monad m) => MonadReaderN (Suc n) r (t m) where askN _ = lift $ askN (Proxy :: Proxy n)

It is important to note that our instances of MonadReaderN are non-overlapping. The instance is uniquely determined by the n :: Nat type parameter.

Finally, we glue the two components together to get a nice ask function:

-- Nice constraint alias type MonadReader r m = MonadReaderN (Find (ReaderT r) m) r m ask :: forall m r . MonadReader r m => m r ask = askN (Proxy :: Proxy (Find (ReaderT r) m)) Problem solved?

Not quite. Both solutions described here do abstract from the position of a monad transformer in the stack, but they do not abstract from the transformer itself. The MonadReader r constraint can only be satisfied with ReaderT r but not, say StateT r. Moreover, a MonadState constraint, defined as

type MonadState s m = MonadStateN (Find (Control.Monad.State.Lazy.StateT s) m) s m

can only be satisfied by the lazy, but not strict, StateT.

I’ll address this issue in a subsequent article.

Categories: Offsite Blogs

Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine

glasgow-user - Mon, 07/14/2014 - 9:53am
Hi, I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine. Here are the specs for my machine: Hardware: MacBook Pro, 13-inch, Mid 2009 Operating System: OS X 10.8.5 gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself. The line that fails is: Earlier in the configuration process I see: Could that be the culprit? The entire installation log can be found here:
Categories: Offsite Discussion

Cabal, Semantic Versioning and Endless Experimental

Haskell on Reddit - Mon, 07/14/2014 - 8:38am

EDIT - Much confusion on my part as the Cabal versioning policy's (PVP) tracks the major version as A.B while Semantic Versioning's major version is only X. The second point confusion was the Semantic Versioning having a distinguished major version zero (0.y.z) which by convention implies instability.

So I was reading the latest about Cabal Hell and thinking about how it just doesn't happen to me anymore as I pretty much follow much of the points outlined in the latest how to avoid Cabal Hell discussion.

And then this morning ... fire and brimstone

The conflict happened as a result of two sets of narrow cabal bounds for attoparsec in two different libriaries.

For the remainder of my thoughts, I'm assuming the principles of Semantic Versioning apply.

To cut to the chase either there is a true conflict or there is not. If not, the bounds can be adjusted in one or both libraries creating an overlapping range or they safely cannot.

At the moment I don't as of yet know which situation applies.

However, all too often it's the latter, a false positive conflict from the overally conservative narrow version bounds. However, I'd do the same myself, i.e. be very conservative in using a narrow attoparsec version bounds as Attoparsec is specific in stating that it is a) Experimental and b) unstable (Semantic Versioning 0.x.y.z versions)

So for the sake of discussion point, and only so, I'll specifically use attoparsec here a bit. Attoparsec was first published 6 years ago with 40+ version releases and is one of the most widely used libs out there as a dependency. Why is the only use option for attoparsec one of experimental / unstable with only 0.x.y.z versions? In other words, why couldn't as least one V1.x have been tied off?

Consider the following situations for a Haskell library developer thinking of using attoparsec this morning:

1) attoparsec as-is is experimental and a 0.x.y.z versioned library subject to at will API modification. => If I use it, I'm going to put a really narrow cabal bounds band on this thing.

2) attoaparsec could-be has a V1.x, V2.x, ... set of releases. Each major release series stable in the sense of a fixed set of functionality and corresponding api + semantics. I can safely set my cabal range on a specific Major.Minor version. IF some user sees a conflict in Major.Minor version down the road, the probability is pretty high that yep, we have a real conflict here and not a case of a pessimistic narrow bounds false positive conflict.

Of course every library has a Experimental phase before solidifying into a minimal viable V1.x library and evolving in a backwards incompatable manner via V2.x ... . However attoparsec has been out there for 6 years, over 40 versions and is wildly successful. Hackage life would be far easier if attoparsec had foundone or more points of library stability along the way.

Once more I'm simply using attoparsec as an example here and not picking on it per se. The main idea here is that if essential, widely used libraries declare themselves experimental and unstable for perpetuity people are going to react by applying very narrow bounds constraints resulting in too frequent false positive conflicts.

submitted by precium
[link] [28 comments]
Categories: Incoming News

mightybyte: Haskell Best Practices for Avoiding "Cabal Hell"

Planet Haskell - Mon, 07/14/2014 - 8:00am
I posted this as a reddit comment and it was really well received, so I thought I'd post it here so it would be more linkable.  A lot of people complain about "cabal hell" and ask what they can do to solve it.  There are definitely things about the cabal/hackage ecosystem that can be improved, but on the whole it serves me quite well.  I think a significant amount of the difficulty is a result of how fast things move in the Haskell community and how much more reusable Haskell is than other languages.

With that preface, here are my best practices that seem to make Cabal work pretty well for me in my development.

1. I make sure that I have no more than the absolute minimum number of packages installed as --global.  This means that I don't use the Haskell Platform or any OS haskell packages.  I install GHC directly.  Some might think this casts too much of a negative light on the Haskell Platform.  But everyone will agree that having multiple versions of a package installed at the same time is a significant cause of build problems.  And that is exactly what the Haskell Platform does for you--it installs specific versions of packages.  If you use Haskell heavily enough, you will invariably encounter a situation where you want to use a different version of a package than the one the Haskell Platform gives you.

2. Make sure ~/.cabal/bin is at the front of your path.  Hopefully you already knew this, but I see this problem a lot, so it's worth mentioning for completeness.

3. Install happy and alex manually.  These two packages generate binary executables that you need to have in ~/.cabal/bin.  They don't get picked up automatically because they are executables and not package dependencies.

4. Make sure you have the most recent version of cabal-install.  There is a lot of work going on to improve these tools.  The latest version is significantly better than it used to be, so you should definitely be using it.

5. Become friends with "rm -fr ~/.ghc".  This command cleans out your --user repository, which is where you should install packages if you're not using a sandbox.  It sounds bad, but right now this is simply a fact of life.  The Haskell ecosystem is moving so fast that packages you install today will be out of date in a few months if not weeks or days.  We don't have purely functional nix-style package management yet, so removing the old ones is the pragmatic approach.  Note that sandboxes accomplish effectively the same thing for you.  Creating a new sandbox is the same as "rm -fr ~/.ghc" and then installing to --user, but has the benefit of not deleting everything else you had in --user.

6. If you're not working on a single project with one harmonious dependency tree, then use sandboxes for separate projects or one-off package compiles.

7. Learn to use --allow-newer.  Again, things move fast in Haskell land.  If a package gives you dependency errors, then try --allow-newer and see if the package will just work with newer versions of dependencies.

8. Don't be afraid to dive into other people's packages.  "cabal unpack" makes it trivial to download the code for any package.  From there it's often trivial to make manual changes to version bounds or even small code changes.  If you make local changes to a package, then you can either install it to --user so other packages use it, or you can do "cabal sandbox add-source /path/to/project" to ensure that your other projects use the locally modified version.  If you've made code changes, then help out the community by sending a pull request to the package maintainer.  Edit: bergmark mentions that unpack is now "cabal get" and "cabal get -s" lets you clone the project's source repository.

9. If you can't make any progress from the build messages cabal gives you, then try building with -v3.  I have encountered situations where cabal's normal dependency errors are not helpful.  Using -v3 usually gives me a much better picture of what's going on and I can usually figure out the root of the problem pretty quickly.
Categories: Offsite Blogs

Avoiding BlockedIndefinitelyOnSTM exceptions

glasgow-user - Mon, 07/14/2014 - 3:30am
I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a -> STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: The original purpose behind this was to easily read and write to a channel without having to count references to the
Categories: Offsite Discussion

Diony Rosa - 7/14/2014 2:14:04 AM

haskell-cafe - Mon, 07/14/2014 - 3:14am Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Bit shifting limitations

libraries list - Sun, 07/13/2014 - 7:36pm
The current state of affairs is a bit unsatisfactory. 1. The biggest problem, as I see it, is that while we have shiftR and shiftL, which are documented as giving 0 or -1 when shifting too far, and we have unsafeShiftR and unsafeShiftL, which are likely to do whatever the CPU happens to do, we don't have anything guaranteed to shift using just the first five or six bits of the shift count, which is what Java specifies and what unsafeShiftR and unsafeShiftL *actually* do (at least on x86_64). I propose that we add these masked shifts to Data.Bits. The default implementations can look something like: shiftRMasked x count | popCount (finiteBitSize x) != 1 = error "Masked shift only makes sense if the size is a power of 2." | otherwise = x `unsafeShiftR` (count .&. (finiteBitSize x - 1)) 2. It would be nice to specify what shiftR and shiftL are supposed to do when given negative shift counts. Is there a practical reason not to specify that? 3. I would like to add explicit arithmetic and logical shifts to
Categories: Offsite Discussion

[ANN] cabal-bounds 0.7: update bounds by haskellplatform release

haskell-cafe - Sun, 07/13/2014 - 1:42pm
Hi cafe, cabal-bounds[1] is a command line program for managing the bounds/versions of the dependencies in a cabal file. cabal-bounds 0.7 adds the feature to set the bounds of dependencies to the library versions used by a haskell platform[2] release. For further details please consult the README[3]. Greetings, Daniel [1] [2] [3]
Categories: Offsite Discussion