News aggregator

Last CFP: ACM Symposium on Applied Computing SoftwareVerification and Testing Track

General haskell list - Tue, 09/23/2014 - 2:21pm
================================================== 30th Annual ACM Symposium on Applied Computing Software Verification and Testing Track April 13 - 17, 2015, Salamanca, Spain More information: and =================================================== Important dates --------------- * September 26, 2014: Submission of regular papers -- EXTENDED * November 17, 2014: Notification of paper acceptance/rejection * December 8, 2014: Camera-ready copies of accepted papers ACM Symposium on Applied Computing ---------------------------------- The ACM Symposium on Applied Computing (SAC) has gathered scientists from different areas of computing over the past twenty-nine years. The forum represents an opportunity to interact with different communities sharing an interest in applied computing. SAC 2015 is sponsored by SIGAPP and will be held at the UNESCO world heritage city of Salamanca in Spain. Software Verification a
Categories: Incoming News

Is it sensible to allow <*> and ap to differ?

Haskell on Reddit - Tue, 09/23/2014 - 10:15am

Here's an example of where it seems sensible to allow <*> and ap to differ. Errors is like Either but it contains a list of "failures" rather than just one. The benefit is that when we program applicatively we can collect all errors at once. If we used the equivalent monadic formulation we would only get the first error.

Is this a sensible thing to do, or is it naughty?

import Control.Applicative import Data.Foldable (sequenceA_) data Errors e a = Errors [e] | Success a deriving Show instance Monad (Errors e) where return = Success Errors es >>= _ = Errors es Success a >>= f = f a instance Functor (Errors e) where fmap _ (Errors e) = Errors e fmap f (Success a) = Success (f a) instance Applicative (Errors e) where pure = Success Errors es <*> Errors es' = Errors (es ++ es') Errors es <*> Success _ = Errors es Success _ <*> Errors es = Errors es Success f <*> Success x = Success (f x) xs :: [Errors Int ()] xs = [Errors [1], Success (), Errors [2]] -- > sequence_ xs -- Errors [1] -- > sequenceA_ xs -- Errors [1,2] submitted by tomejaguar
[link] [17 comments]
Categories: Incoming News

Copyright field vs. License file

haskell-cafe - Tue, 09/23/2014 - 9:16am
Dear package maintainers, a lot of our LICENSE file start like tihs: ==> haskell-lens- <== Copyright 2012-2014 Edward Kmett All rights reserved. ... ==> haskell-cryptocipher-0.6.2/LICENSE <== Copyright (c) 2010-2013 Vincent Hanquez <vincent< at >> All rights reserved. ... ==> haskell-http-client- <== The MIT License (MIT) Copyright (c) 2013 Michael Snoyman Permission is hereby granted, free of charge, to any person obtaining a copy of ... i.e. they mix the copyright information with the license. I know, of course, why that is: "cabal init" prepares it that way, and those not using cabal init probably copy it from an existing file. A notable exception are the GPL-licensed packages; these usually don’t have copyright information in the license. The problem is that this information is not structured, and ha
Categories: Offsite Discussion

ANNOUNCE: bv-0.3.0

haskell-cafe - Tue, 09/23/2014 - 9:14am
I am pleased to announce a new release of the bv package, a library for bit-vector arithmetic. This is essentially a maintenance release to support newest versions of GHC and base. Yet, I took the opportunity to do some code and documentation clean up. A changelog is available at Iago _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

usage of traversal

haskell-cafe - Tue, 09/23/2014 - 6:27am
Hi, Recently, I need to write the following code: getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = case mfile of Nothing -> return Nothing Just file -> Just <$> getModificationTime file I feel that this is redundant. So, I used 'traverse' instead: getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = getModificationTime `traverse` mfile First, I would like to know whether or not this is a good coding style. Second, if this is acceptable, why don't we define an operator? For instance, (<:>) :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) (<:>) = traverse getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = getModificationTime <:> mfile Is there such an operator already? Regards, --Kazu
Categories: Offsite Discussion

Well-Typed.Com: Haskell courses and Haskell eXchange

Planet Haskell - Tue, 09/23/2014 - 4:10am

In the beginning of October, my colleage Adam Gundry and I will spend a full week in London again for Haskell-related activities: on Monday and Tuesday (October 6–7), we will teach Fast Track to Haskell, a two-day introduction course to Haskell, targeted at people who want to get started with Haskell or learn more about functional programming in general. On Wednesday (October 8), there’s the Haskell eXchange, a one-day conference full of interesting talks on Haskell-related topics. On Thursday and Friday (October 9–10), we will look at more advanced Haskell concepts and programming patterns in Advanced Haskell.

All three events are still open for registration.

Haskell eXchange

The Haskell eXchange will take place in London for the third time now, and I’m happy to report that there’s going to be a really fantastic program again:

As is almost traditional by now, Simon Peyton Jones (Microsoft Research) himself will open the conference, this time with a talk on “Safe, zero-cost coercions in Haskell”.

This is followed by Jeremy Gibbons (University of Oxford) with “Categories for the Working Haskeller”, explaining to Haskell developers and people who are interested in Haskell what role category theory plays in Haskell and if/how categories can be helpful.

I’m very pleased that Bryan O’Sullivan (Facebook) has agreed to give a presentation at the Haskell eXchange this year. As the author of countless Haskell libraries (many of which are among the most used in the entire Haskell ecosystem), and being a co-author of the widely known O’Reilly book “Real World Haskell”, he’s certainly learned how to squeeze a bit of extra performance out of Haskell code when needed. He’s going to share his experiences and provide valuable advice in his talk.

After lunch, we’ll continue with a pair of talks looking at using Haskell for the development of RESTful web services from slightly different angles. Erik Hesselink (Silk) is going to present the rest framework, which makes it easy to develop and maintain REST APIs, independent of the underlying web framework you use. After that, Chris Dornan (Iris Connect) and Adam Gundry (Well-Typed) will talk about api-tools and in particular address the question of how you can solve the problem of schema migrations nicely.

Tim Williams and Peter Marks (both Barclays) will give a joint talk on Lucid, their in-house non-embedded DSL that is written in Haskell and has a mostly structural type system with interesting features such as row polymorphism and extensible records as well as extensible sum-types.

The talks will be concluded by Oliver Charles (Fynder), well-known for his tireless efforts in the “24 days of Hackage” series, who is going to show us how the use of GHC’s most advanced type system extensions helps him write better real-world code at his company.

After the talks, there’s going to be pizza and beer and an informal “Park Bench Discussion” where we can all discuss the questions that have been raised throughout the day in more detail.

I hope you’re as excited about this program as I am: I think there’s a fantastic range of topics covered, from language features and theoretical aspects, practical advice for programmers to interesting case studies of real-world code. Also, it’s an excellent opportunity to meet fellow developers interested in Haskell. If you’re working for a company using Haskell and are looking for new developers, this may be an excellent opportunity to recruit. On the other hand, if you’d like nothing more than a Haskell job, this is an opportunity to meet people who are actually using it in practice, and may have a job for you or at least be able to give you advice on how to find one.

If you haven’t registered yet, please consider doing so! We’re looking forward to meeting you there.

Fast Track to Haskell and Advanced Haskell

These two successful courses have been offered on a regular basis since October 2012. They’re continuously updated to reflect the latest changes in the Haskell world, such as updates to the infrastructure, new features of the main Haskell compiler GHC, or exciting new libraries.

Both courses are hands-on, comprising a combination of lectures, interactive coding and exercises that the participants are supposed to work on alone or in teams, with the help of the teacher(s).

The Fast Track course is for people who know how to program, but have little or no experience in Functional Programming or Haskell. It teaches Haskell in from scratch in just two days, covering important concepts such as datatypes, polymorphism, higher-order functions, type classes, how IO works in Haskell, and ending with an introduction to monads. It’s also interesting for people who are interested in learning about functional programming in general, because Haskell is a prime example of a functional programming language, and the course focuses on the important programming concepts more than on language peculiarities.

The Advanced Haskell course is for people who have some experience with Haskell, but want to learn more. We’re going to discuss (functional) data structures and their complexity, have a detailed look at how lazy evaluation works and how it is implemented, how to reason about performance and how to use various debugging tools. Somewhat depending on demand, there’s also the option to learn more about advanced programming patterns, such as monads, applicative functors and monad transformers, about concurrency and parallelism, or about the more advanced features of the Haskell type system such as GADTs and type families.

Being in the same week as the Haskell eXchange makes it possible to combine one of the courses (or even both) with the eXchange, where you can hear several other viewpoints and get to know more Haskellers!

Other courses

We’re offering additional training courses on-demand and on-site for companies in Europe, the US, or anywhere in the world on request. See our training page for more information.


By the way, I’m also going to be at the Haskell Hackathon in Berlin this upcoming weekend. On Sunday, I’m going to give a talk on parser combinators. You can still register for the Hackathon, too. It’s free.

Categories: Offsite Blogs

Haskell documentation woes

Haskell on Reddit - Tue, 09/23/2014 - 3:31am

I use a docker container for haskell development and ever since hackage stopped building their documentation, I've had a really hard time accessing package documentation.

I reinstalled all the packages with the "--enable-documentation" flag. And now I have the documentation installed. But since the docs are inside the container I'm not able to view them with a browser.

I tried copying the documentation to the host and was successful. I was able to open the "index.html" pages. But the links inside the documentation are broken after copying them to the host. This is because haddock uses absolute urls when generating the documentation.

I then tried using hoogle to see if I can serve the documentation of the installed packages.. But that did not work either.

I really don't know what else to try.

Can someone please point me in a sane direction. Been pulling my hair over this for the past few days. Without package documentation, I haven't been able to do anything.

submitted by desijays
[link] [13 comments]
Categories: Incoming News

LtU's new server

Lambda the Ultimate - Tue, 09/23/2014 - 1:26am
Lambda the Ultimate is now running on a new, faster, more reliable server. The old one is now, uh... pining for the fjords. This should resolve the increasingly frequent outages we've seen recently. Because the old server had started failing, we didn't have time to do as much quality control on the migration as we would have liked. If anyone notices any issues with the site, please comment in this thread. Currently known issues:
  • Non-Latin UTF-8 characters apparently didn't survive the database migration correctly. This is a particular issue if you have a username containing non-Latin characters - you may not be able to log in currently.
  • It's possible that some comments posted later on Monday don't appear on the new site. (Resolved: there were no missing comments)
  • New user signup emails are not yet working.
  • Due to DNS propagation, not everyone will see the new site immediately. (Now resolved)
The struck out issues have been resolved. The remaining issue, with user signup emails, should be resolved in the next few days.
Categories: Offsite Discussion

Implementing FRP in C++

Haskell on Reddit - Mon, 09/22/2014 - 8:57pm

I'm working on a project in C++ where I need to have an event manager. As it gets more complex, my early hacky solutions might not work anymore and I don't know enough about these things to predict how. I've been reading about FRP recently and it sounds really cool and learning about how it's implemented might help me prevent issues before they happen. I almost definitely won't need the full power of FRP but I'd like to learn more. Most of the tutorials I could find out there only talk about how to use existing FRP libraries.

Two questions.

  1. Where's the best place to learn about how to implement FRP?

  2. How are the semantics defined? If I understood this well enough (I hope) I could implement something. A lot of the guides out there skip over a lot of the messy details that I want to understand.

I need to be able to regularly check for events of several types known at compile time and check whether they need to be fired as often as they need to be, which is the maximum frequency of any listener to the event, or never if there are no listeners. Listeners can change dynamically over time. Triggering a listener might register or unregister other listeners and the side effects of triggering one listener should happen before triggering the next listener.

The event checking is a bit complicated too. Related events depend on the same processing, and that processing should happen if and only if it's needed for any of the events that depend on it.

I probably don't need the full power of FRP, but the system might get more complicated over time.

submitted by expwnent
[link] [5 comments]
Categories: Incoming News

Yesod Web Framework: The woes of multiple package versions

Planet Haskell - Mon, 09/22/2014 - 6:00pm

When I've answered the same question more than three times, it's usually time to write up a blog post explaining the situation in more detail, and just link people to that in the future. This is such a blog post.

Many people working with Haskell end up with one of these two classes of inexplicable GHC errors:

  1. Cannot match ByteString with ByteString, with a whole bunch of package name and version junk as well.

  2. SomeTransformerT is not an instance of MonadTrans, when the documentation clearly indicates that SomeTransformerT does define such an instance.

How can a ByteString not be a ByteString? Well, there are two ways I can think of. The first is that you're accidentally trying to mix up a strict ByteString with a lazy ByteString, whose types clearly don't unify. While that problem does pop up, in my experience most people figure that one out pretty quickly. By the time someone's asking a question on Stack Overflow/Reddit/haskell-cafe, it's usually much more insidious: there are two copies of bytestring on their system.

Imagine this situation: you install GHC 7.6, which ships with bytestring- You then install text via cabal install text. A few days later, someone mentions that bytestring- is out, and it's all new and shiny, so you go ahead and install it with cabal install bytestring. Everything works wonderfully, and life is good. Then you decide to experiment with text a bit, so you write the following program:

{-# LANGUAGE OverloadedStrings #-} import Data.Text.Encoding (encodeUtf8) import qualified Data.ByteString.Char8 as S8 main :: IO () main = S8.putStrLn $ encodeUtf8 "Hello World!"

Woe unto you! GHC rejects your program with:

foo.hs:6:22: Couldn't match expected type `S8.ByteString' with actual type `bytestring-' In the return type of a call of `encodeUtf8' In the second argument of `($)', namely `encodeUtf8 "Hello World!"' In the expression: S8.putStrLn $ encodeUtf8 "Hello World!"

When is a ByteString not a ByteString? Here, apprently. Now it turns out the GHC is actually giving you quite of bit of useful information, you just need to know what to look for. It's expecting the type S8.ByteString, which expands to Data.ByteString.Char8.ByteString, which in reality is just a type synonym for Data.ByteString.Internal.ByteString. So what GHC really means is that it can't unify the following two types:

expected: Data.ByteString.Internal.ByteString actual: bytestring-

Now the difference just jumps out at you: the actual type comes from the bytestring- package, whereas the first comes from... well, somewhere else. As I'm sure you're guessing right now, that "somewhere else" is bytestring-, but GHC doesn't bother telling us that, since including that level of information in every error message would be overwhelming. To step through why this came up exactly:

  • text is installed against bytestring- (it was the only version of bytestring available at the time you installed text).
  • Therefore, encodeUtf8 will generate a ByteString value from version
  • Your program imports Data.ByteString.Char8, which is provided by both bytestring- and bytestring-
  • GHC's default dependency resolution is: take the latest version of each package, in this case
  • Now we have a S8.putStrLn function expecting a ByteString, but an encodeUtf8 function returning a ByteString.

So how do we work around this problem? I can think of three ways:

  1. Explicitly tell GHC which version of the bytestring package you want to use to force consistency, e.g. runghc -package=bytestring- foo.hs.
  2. Never use GHCi, runghc, or ghc directly from the command line. Instead, always create a cabal file first. cabal's default dependency resolution will force consistent package loading.
  3. Don't wind up in the situation in the first place, by ensuring you only have one version of each package installed.

That last point is what I strongly recommend to all users. And this is exactly the design goal around Stackage, so it will hopefully not come as a surprise that that's exactly what I recommend most Haskell users use to get their packages installed.

Let's demonstrate that second case of MonadTrans. This time, let's try it with GHC 7.8.3. GHC ships with transformers- Next, we'll install the either package with cabal install either. Once again, someone comes along and tells us about a shiny new package, transformers- Dutifully, we upgrade with cabal install transformers- And then we try to run the following simple program:

import Control.Monad.Trans.Class import Control.Monad.Trans.Either main :: IO () main = do x <- runEitherT $ lift $ putStrLn "hey there!" print (x :: Either () ())

GHC mocks you with:

foo.hs:6:23: No instance for (MonadTrans (EitherT ())) arising from a use of ‘lift’ In the expression: lift In the second argument of ‘($)’, namely ‘lift $ putStrLn "hey there!"’ In a stmt of a 'do' block: x <- runEitherT $ lift $ putStrLn "hey there!"

"But EitherT is an instance of MonadTrans!" you insist. That may be true, but it's an instance of the wrong MonadTrans. The either package is built against transformers-, whereas you've imported lift from transformers- This can be worked around as above, with runghc -package=transformers- foo.hs. And yet again, my strong recommendation is: use Stackage.

There's one more particularly painful thing I need to point out. Some packages are bundled with GHC, and are depended on by the ghc package. The special thing about the ghc package is that it cannot be reinstalled without installing a new version of GHC itself. Any packages depended on by the ghc package cannot be unregistered without breaking ghc, which would in turn break libraries like doctest and hint. If you follow these points to conclusion, this means that you should never upgrade GHC-bundled libraries. I wrote a blog post on this topic, and the takeaway is: please, always support older versions of packages like bytestring, transformers, and- of course- base.

There's one final case I want to mention. Try running cabal install data-default-0.5.1 http-client, and then run the following program:

import Data.Default import Network.HTTP.Client main :: IO () main = withManager defaultManagerSettings $ \man -> do res <- httpLbs def man print res

You'll get the irritating error message:

foo.hs:6:20: No instance for (Default Request) arising from a use of ‘def’ In the first argument of ‘httpLbs’, namely ‘def’ In a stmt of a 'do' block: res <- httpLbs def man In the expression: do { res <- httpLbs def man; print res }

But if you look at http-client, Request is in fact an instance of Default. "Alright, I know what's going on here" you say. Certainly there are two versions of data-default installed, right? Actually, no, that's not the case. Have a look at the following:

$ ghc-pkg list | grep data-default data-default-0.5.1 data-default-class-0.0.1

There's just a single version of each of these packages available. So why are we getting our mysterious error message? Once again, it's because we have two versions of the Default class. After data-default version 0.5.1, data-default split into a number of packages, and the Default class migrated into data-default-class. http-client defines an instance for Default from data-default-class. And if you use data-default version 0.5.2 or higher, it will simply re-export that same class, and everything will work.

However, our cabal install command forced the installation of the older data-default (0.5.1) which defines its own Default typeclass. Therefore, we end up with two separate Default classes that don't unify. This is a problem that exists whenever packages are split or joined, which is why you should embark on such refactorings with great care.

As it happens, this is yet another problem that is solved by using Stackage, since it forces a consistent set of versions for data-default and data-default-class.

Categories: Offsite Blogs

Postdoctoral Position in Programming Languages at KULeuven

General haskell list - Mon, 09/22/2014 - 4:34pm
Postdoctoral Position in Programming Languages at KU Leuven The Declarative Languages and Artificial Intelligence (DTAI) group of KU Leuven (Belgium) invites applicants for a postdoctoral position in the area of programming languages. This position has been created at the occasion of the new appointment of prof. Tom Schrijvers as research professor at KU Leuven. The position's aim is to reinforce the research activities in functional programming, logic programming and/or programming language theory. To apply you must hold a recent PhD (or be about to graduate) in one of the above areas of programming languages. Candidates are expected to have high-quality publications in peer-reviewed conferences and journals. The postdoc will work closely with prof. Schrijvers and his PhD students, participate in ongoing research activities and enjoy the freedom to develop new lines of research. The position is for 2 x 1 year and can be further extended. The salary is competitive and the starting date negotiable. Moreo
Categories: Incoming News

Philip Wadler: Composable Queries in F# 3.0

Planet Haskell - Mon, 09/22/2014 - 3:52pm
James Cheney speaks to the F#unctional Londoners meet-up about our F# library that implements A Practical Theory of Language-Integrated Query.
Categories: Offsite Blogs