News aggregator

FP Complete: MinGHC for GHC 7.10

Planet Haskell - Fri, 03/27/2015 - 3:30am

We're happy to announce the availability of MinGHC for GHC 7.10. MinGHC is a minimal GHC installer for Windows, consisting of:

  • GHC itself
  • cabal-install
  • MSYS, which is necessary for building some packages such as network

MinGHC came out of some conversation Neil Mitchell and I had at ICFP last year about pain on the Windows platform, and consists of a lot of good code by Neil, and some hacky attempts by me at understanding Windows installer processes. While this project predates the Commercial Haskell SIG by a few months, it's essentially the first project undertaken by the group.

While MinGHC is relatively young, it's also a minimalistic product, simply repackaging and serving upstream components unmodified. Additionally, it has become the recommended installer by quite a few sites, and therefore has already received significant testing. Also, due to its minimal nature, it's easy to pop out new releases of MinGHC. For example, this current release was made less than two hours after GHC itself was released!

While this project is stable, additional testers and contributors are certainly welcome. Please check out the Github project page for more information.

Categories: Offsite Blogs

ANNOUNCE: GHC version 7.10.1

Haskell on Reddit - Fri, 03/27/2015 - 1:49am
Categories: Incoming News

Breathing Code - Fri, 03/27/2015 - 1:02am
Categories: Offsite Blogs

Breathing Code - Fri, 03/27/2015 - 1:02am
Categories: Offsite Blogs

Haskell Weekly News: Issue 322

General haskell list - Thu, 03/26/2015 - 11:24pm
New Releases 99 Haskell: A web service by Bram Hoskin Solve live Haskell coding problems based on H-99 in the browser to strengthen your understanding of the language. Magic Cookies A commercial Android game is released that is written in Haskell using SDL2 for multimedia and the Arrowized Functional Reactive Programming DSL Yampa. The authors had to "escape their functional comfort zones and come up with smarter abstractions that mutable reality and performance demand". The game consists of 2K lines of code, of which 1K is game specific and 400 are Yampa code. The most complex parts were certain Yampa constructs (arrow-based, with lots of tupling/untupling). https://github.c
Categories: Incoming News


libraries list - Thu, 03/26/2015 - 9:19pm
ansi-wl-pprint sits underneath a large chunk of our infrastructure: test-framework, criterion, trifecta, etc. Transitively through those dependencies it affects a very large percentage of the Haskell packages we have today, because you can't build almost anybody's testing and benchmarking frameworks without it. We recently had to push out an non-maintainer update for GHC 7.10-rc3 compatibility, and due to NMU update guidelines meant we had to wait 2 weeks before we could do anything. This pretty much ensured that the entire 7.10-rc3 release cycle went by with very very few people able to run their test suites, and little testing was able to be performed in the allotted window. Fortunately, Neil managed to find a rather large regression on his own during this time: That said, given that we found issues with linear caused by the changes to Typeable, once we fixed the test suite, this gives me pause. I'm pretty sure nobody downstream of linear tr
Categories: Offsite Discussion

Danny Gratzer: Value vs Monomorphism Restriction

Planet Haskell - Thu, 03/26/2015 - 6:00pm
Posted on March 27, 2015 Tags: sml, haskell

I’m taking the undergraduate course on programming languages at CMU. For the record, I still get really excited about the novelty of taking a class (at school!) on programming languages. I’m easily made happy.

We started talking about System F and before long we touched on the value restriction. Specifically, how most people think of the value restriction incorrectly. To understand why this is, let’s first define the value restriction since it’s probably new to you if you don’t use SML.

The Value Restriction

In SML there are value level declarations just like in Haskell. We can write things like

val x = 1 val y = x + 1

and we end up with x bound to 1 and y bound to 2. Note that SML is strict so these bindings are evaluated right as we reach them. Also like in Haskell, SML has polymorphism, so we can write map

fun map f [] = [] | map f (x :: xs) = f x :: map f xs

And it gets the type ('a -> 'b) -> ('a list -> 'b list). Aside from minor syntatic differences, this is pretty much identical to what we’d write in Haskell. The value restriction concerns the intersection of these two things. In SML, the following should not compile under the standard

val x = rev []

This is because SML requires that all polymorphic val bindings be values! In practice all implementations will do something besides this but we’ll just focus on what the standard says. Now the reason for this value restriction is widely misunderstood. Most people believe that the value restrictions

val r = ref NONE val () = r := SOME 1 val _ = case !r of SOME s => s | NONE => ""

This seems to illustrate a pretty big issue for SML! We’re filling in polymorphic reference with one type and unboxing it with a different one! Clearly this would segfault without the value restriction. However, there’s a catch.

SML is based on System F (did you really think I could get through a blog post without some theory?) which is sometimes called the “polymorphic lambda calculus”. It’s the minimal language with polymorphism and functions. In this language there’s a construct for making polymorphic things: Λ.

In this language we write polymorphism explicitly by saying Λ τ. e which has the type ∀ t. T. So for example we write the identity function as

id ≡ Λ τ. λ x : τ. x () = id[unit] ()

Now SML (and vanilla Haskell) have a limited subset of the power of Λ. Specifically all these lambdas have to appear at the start of a toplevel term. Meaning that they have to be of the form

val x = Λ α. Λ β. ... e

This is called “prenex” form and is what makes type inference for SML possible. Now since we don’t show anyone the hidden Λs it doesn’t make sense to show them the type application that comes with them and SML infers and adds those for us too. What’s particularly interesting is that SML is often formalized as having this property: values start with Λ and are implicitly applied to the appropriate types where used. Even more interesting, how do you suppose we should evaluate a Λ? What for example, should this code do

val x = Λ τ. raise[τ] Fail (* Meaning raise an exception and say we have type τ *) val () = print "I made it here" val () = x[unit]

It seems clear that Λ should be evaluated just like how we evaluate λ, when we apply it. So I’d (and the formalization of SML) would expect this to print "I made it here" before throwing that exception. This might now surprise you just by parallels with code like this

val x = fn () => raise[τ] Fail val () = print "I made it here" val () = x ()

However, what about when those lambdas are implicit? In the actual source language of ML our code snippet would be

val x = raise Fail val () = print "I made it here" val () = x[unit]

Uhoh, this really looks like it ought to throw an exception but it apparently doesn’t! More worringly, what about when we have something like

fun die () = raise Fail val x = die () val () = print "Made it here"

Since x is never specialized, this doesn’t even throw an error! Yikes! Clearly this is a little confusing. It is however, type safe. Consider our original motivation for the value restriction. With explicit type application

val r = Λ τ. ref[τ] NONE val () = r[int] := SOME 1 val _ = case !(r[string]) of SOME s => s | NONE => ""

Since the body of this function is run every time we do something with r, we’re just creating a whole bunch of new references in this code! There’s no type safety failure since !(r[string]) returns a fresh ref cell, completely different from the one we modified on the line above! This code always runs the NONE case. In fact, if this did the wrong thing it’s just a canary in the coal mine, a symptom of the fact that our system evaluates under (big) lambda binders.

So the value restriction is really not at all about type safety, it’s about comprehensibility. Mostly since the fact that a polymorphic expression is evaluated at usage rather than location is really strange. Most documentation seems to be wrong about this, everyone here seems agree that this is unfortunate but such is life.

The Monomorphism Restriction

Now let’s talk about the monomorphism restriction. This is better understood but still worth recapping. In Haskell we have type classes. They let us overload function to behave differently on different types. Everyone’s favoriate example is the type class for numbers which let’s us write

fact :: (Eq a, Num a) => a -> a fact 0 = 1 fact n = n * fact (n - 1)

And this works for all numbers, not just int or something. Under the hood, this works by passing a record of functions like *, fromInteger, and - to make the code work. That => is really just a sort of function arrow that happens to only take particular “implicit” records as an argument.

Now what do you suppose the most polymorphic type this code is?

x = fact 10000

It could potentially work on all numbers so it gets the type

x :: (Num a, Eq a) => a

However this is really like a function! This means that fact :: Integer and fact :: Int evaluate that computation twice. In fact each time we call fact we supply a new record and end up evaluating again. This is very costly and also very surprising to most folks. After all, why should something that looks like a normal number evaluate every time we use it! The monomorphism restriction is essentially

  1. If you have a binding
  2. Whose type is (C1, C2 ...) => t
  3. And has no arguments to the left of the =
  4. Don’t generalize it

This is intended to keep us from the surprise of evaluating a seemingly fully reduced term twice.

Sound familiar? Just like with the value restriction the whole point of the monomorphism restriction is to prevent a hidden function, either type abstraction or type constraints, from causing us to silently and dangerously duplicate work. While neither of them are essential to type safety: without it some really simple looking pieces of code become exponential.

Wrap Up

That about covers things. It turns out that both of these restrictions are just patches to cover some surprising areas of the semantics but both are easily understood when you look at the elaborated version. I deliberately went a bit faster through the monomorphism restriction since quite a lot of ink has already been spilled on the subject and unlike the value restriction, most of it is correct :)

As one final note, the way that Haskell handles the monomorphism restriction is precisely how OCaml handles the value restriction: weak polymorphism. Both of them mark the type variables they refuse to generalize as weak type variables. Whenever we first instantiate them to something we go back and retroactively modify the definition to pretend we had used this type all along. In this way, we only evaluate things once but can handle a lot of simple cases of binding a value and using it once.

The more you know.

<script type="text/javascript"> var disqus_shortname = 'codeco'; (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = '//' + disqus_shortname + ''; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })(); </script> <noscript>Please enable JavaScript to view the comments powered by Disqus.</noscript> comments powered by Disqus
Categories: Offsite Blogs

Manuel M T Chakravarty: Schrödinger’s Box

Planet Haskell - Thu, 03/26/2015 - 5:43pm

In Objective-C, NSValue provides a universal container that can hold scalars and value types in addition to references. Conversely, in Swift, we quickly learnt to appreciate Box<T> as a wrapper to embed (cyclic) references in enums and structs (especially due to limitations in the initial versions of the Swift compiler):

final public class Box<T> { public let unbox: T public init(_ value: T) { self.unbox = value } }

NSValue is also useful to wrap reference. For example, if we want to turn a strong reference into a weak reference (possibly to store it in a collection, such as NSArray), we can create an NSValue with +valueWithNonretainedObject.

How do we achieve that in Swift without losing type information, as using NSValue would? We use Schrödinger’s Box:

final public class WeakBox<T: AnyObject> { private weak var box: T? public var unbox: T? { get { return box } } public init(_ value: T) { = value } }

You can put something into Schrödinger’s Box, which will or will not be gone by the time you try to retrieve it. It enables, for example, to build a typed collection of weakly referenced objects (to avoid retain cycles).

NB: The definition of WeakBox is fine with the latest Swift 1.2 compiler. However, the Swift 1.1 compiler can only handle it with -Onone; otherwise, it crashes.

Categories: Offsite Blogs

Neil Mitchell: New website with new talks

Planet Haskell - Thu, 03/26/2015 - 4:01pm

My website is now located at and has a few new talks on it:

My old website at is going to stop being updated, and I'll be putting in redirections shortly. That server is going to stop hosting websites, so I bought myself a domain name and setup a GitHub pages website. The repo is here, including all the data, metadata, templates and scripts.

Categories: Offsite Blogs

Do we have idiom for lifting a state monad into pairof states?

haskell-cafe - Thu, 03/26/2015 - 9:28am
Consider you have developed library routines that act on (State s1 a). For some reason, you need more than one state simultaneously. Let's say two side by side for simple example, that is (State (s1,s2) a). To use library functions on one state monad in a two state monad, we need to wrapper that lifts actions of (State s1 a) to (State (s1,s2) a). It is not difficult to write a lifter for such purposes as below. It is kind of like doing liftA in Applicative libarary, but instead of the last argument 'a' but on the fist argument 's' of (State s a). This seems like an idiom that can often come up. So, I tried some searching in some applicative related libraries and monad transformer related libraries but haven't found this idiom yet. If you had a need for idioms like below, what do you call it? Or, is there a way more general way I've missed that makes this a very special case of it. > import Control.Monad.State > import Control.Monad.Error > import Control.Applicative > > -- lift an action ov
Categories: Offsite Discussion

VSTTE 15, Second Call for Papers

General haskell list - Thu, 03/26/2015 - 8:41am
********************************************************************** 7th Working Conference on Verified Software: Theories, Tools, and Experiments July 18 - 19, 2015 San Francisco, California, USA Co-located with 25th Conference on Computer Aided Verification ( ********************************************************************** Full Paper Submission Deadline: April 27, 2015 SCOPE: The Seventh Working Conference on Verified Software: Theories, Tools, and Experiments follows a successful inaugural working conference at Zurich in 2005 followed by conferences in Toronto (2008), Edinburgh (2010), Philadelphia (2012), Atherton (2013), and Vienna (2014). The goal of this conference is to advance the state of the art in the science and technology of software verification, through the interaction of theory development, tool evolution, and experimental validation. We welcome submissions describing significant advances in the production of verified s
Categories: Incoming News

I'm gonna Write Myself A Scheme - any things I should look out for (a la the RWH problems)?

Haskell on Reddit - Thu, 03/26/2015 - 8:18am

If you hav any questions, just ask!

Edit: Hey, why the downvote? I'd think requesting errata for one of the most popular intermediate-level Haskell tutorials is "Constructive".

submitted by octatoan
[link] [8 comments]
Categories: Incoming News

how to determine the physical harddrive a file is on?

Haskell on Reddit - Thu, 03/26/2015 - 4:27am

Hello there, I had some haskell in university but have a strong scala background and decided to give haskell a try again. My first haskell post ever...

As an useful exercise, I want to write a duplicate scanner, which shall run in parallel. However, the parallelization factor should match the amount of >physical drives< that have to be scanned. Logical drives / partitions would likely decrease performance because then the HD head has to jump uselessly. For that, I need a way to determine the drive and in particular distinguish logical from physical drives. In scala/ on the JVM, this doesn't seem to be possible, so I resorted to an external bash command. Is this possible in haskell directly?

submitted by ib84
[link] [6 comments]
Categories: Incoming News