# News aggregator

### What are your documentation browsing workflows?

I usually Google to find documentation on Hackage, and I have 10-20 Hackage tabs open at a time. This is pretty slow, but I haven't found anything better.

How do other people browse documentation?

submitted by anon_c[link] [19 comments]

### Pattern Matching: Wot's... Uh the Deal?

### Fold-Based Fusion as a Library (pdf)

### Beginner question: Stuck while trying to log function parameters. Please help.

Here is the code https://bpaste.net/show/ea9c9b525b1d

I asked about this in IRC, where some one told me that it was not possible, but can make it work using some 'clever tricks'. I worked on it some more and made this,

https://bpaste.net/show/717d1572d053

which works as expected. I asked about these again in the IRC when someone else told me that it does not obey the Monad laws. so cannot work with composition. He also suggested changing the type signature and add a new function.

showReturn :: (Show a) => a -> Writer a showReturn x = Writer ("I got: " ++ show x) x

So I tried doing this http://lpaste.net/133284 , but didn't work. I couldn't ask the guy because he got disconnected..

Can you tell me if what I originally inteded to do with https://bpaste.net/show/ea9c9b525b1d is possible with actual Monads. The guy from irc also told me that one can make the second version, https://bpaste.net/show/717d1572d053, to work with do notation using overloading 'do'. How is this done?

Thank you.

submitted by yet-i[link] [2 comments]

### Learn You A Haskell read-through

Hey Guys, I've been going through Learn You a Haskell, and to challenge myself, I've been trying to implement every function the author uses/talks about that he never explicitly says how to write. However, this has been taking quite a while, especially with the modules chapter, and I was wondering if there are diminishing returns to this approach. Should I keep on doing this and reap the benefits later, or just read through and move quicker to actual projects/harder stuff?

submitted by uncountableB[link] [11 comments]

### ShowerThoughts: The name Haskell sounds ugly which affects its popularity

The newer languages gaining popularity have cool names: Swift, Scala, Go, Rust, Elixir.

If Haskell were named something fun like Rad or Beem all the cool kids would use it.

submitted by srbufi[link] [10 comments]

### Effectful Haskell: IO, Monads, Functors

### HaskellForms - WinForms bindings for Haskell

Hey. I've been working on this for a short while so I thought I'd share. It's currently nowhere near usable but if you're feeling adventerous, you might like giving it a shot.

https://github.com/LukaHorvat/HaskellForms

There's a shortish blog post about it here http://lukahorvat.github.io/programming/2015/05/24/haskellforms/

You might need the F# redistributable (maybe try this link: https://www.microsoft.com/en-us/download/details.aspx?id=44941) I'm not sure because I don't have a PC without VS handy.

Oh, btw. The way I test it is by running cabal repl, then startHost False (you'll be asked if you want to debug with VS, I'm not sure what happens if you don't have it), then main.

submitted by Darwin226[link] [8 comments]

### Feedback wanted, small cli questionnaire using cassava

I've made a script that asks the user a questionnaire and stores the results in a csv file. Just meant for self-monitoring.

I'd appreciate any all all feedback. In particular, I'm looking for better ways of...

- storing the questions themselves (currently individual functions in Questions.hs)
- creating the instances FromNamedRecord, FromRecord, ToRecord, etc for Answer
- asking the questions in the function ask

In general I want to use the named records, and have a header in the csv file, but I haven't been able to figure out to do it. I think it's very tedious to write the header manually/explicitely, I'd like to be able to have one automatically generated from the record defintion of Answer (same thing I'd want for the instances mentioned above). How can this be acheived?

submitted by jarlg[link] [2 comments]

### Everybody hates Cabal, so why use it?

I've only really heard people complaining about Cabal. Surely we could all agree to use (and develop if necessary) some other tool? Why keep using Cabal? What should we use instead?

Edit: or just work to improve Cabal! That's probably the best option (yes, I know there are people working on it right now, but perhaps be more radical)

Edit 2: a lot of people seem upset about the title of this post! I can't change it, but I apologize. Not everybody hates Cabal - in fact it looks like the majority is okay with it. Honestly, this post wasn't intended to be a jab at Cabal, but to explore what its problems are, and possible solutions for those problems.

submitted by Alyte[link] [92 comments]

### Philip Wadler: Stylish Academic Writing

### overlapping instances in 7.10.1

### Should I bring Haskell into a corporate environment and if so, how?

I've been given the opportunity to develop a small piece of code (with future expansion if it goes well) in any language of choice. This piece of code is meant to build a RESTful API within a microservice framework. Should I use Haskell for this and if so, what is the best way of integrating Haskell into the project? Keep in mind that I'm pretty new to Haskell myself and am trying to show to the hardcore Java developers that this is a real alternative. Frameworks and best practices would be appreciated as well.

submitted by haskelldrone[link] [77 comments]

### Munich Haskell Meeting, 2015-05-25 < at > 19:30

### Well-Typed.Com: Parametricity Tutorial (Part 1)

A powerful feature of Haskell’s type system is that we can deduce properties of functions by looking *only at their type*. For example, a function of type

can only be the identity function: since it must return something of type a, for *any* type a, the only thing it can do is return the argument of type a that it was given (or crash). Similarly, a function of type

can only do one of two things: either return the first argument, or return the second. This kind of reasoning is becoming more and more important with the increasing use of types such as this definition of a “lens”:

type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f tSince a lens is just a function of a particular type, the only thing we can conclude about such a function is whatever we can deduce from its type.

To reason about the properties of functions based only on their types we make use of the theory of parametricity, which tells how to derive a so-called “free theorem” from a type. This blog post is a tutorial on how to do this; it won’t explain *why* the theory works, only *how* it works. A Haskell practitioner’s guide to parametricity, if you will.

This is a two-part blog post. In part 1 (this post) we will cover the basics: constant types, functions and polymorphism (over types of kind *).

In part 2 (to be published shortly) we will deal with more advanced material: type constructor (types of kind * -> *), type classes, polymorphism over type constructors and type constructor classes.

The BasicsThe main theorem of parametricity is the following:

if f :: t then f ℛ(t) fWhen t is a closed type, ℛ(t) is a relation between two terms of type t (we shall see later that the type of ℛ is actually slightly more general). In words, parametricity states that any term f of type t is related to itself by ℛ(t). Don’t worry if this all looks incredibly abstract! We shall see lots and lots of examples.

Constant types (types of kind *)For any constant type C, the relation ℛ(C) is the identity relation. In other words,

x ℛ(C) x' iff x ≡ x'(We will use ≡ throughout to mean mathematical equality, to distinguish it from Haskell’s equality function (==).)

Let’s see an example. Suppose that x :: Int. Then parametricity tells us that

x ℛ(Int) x iff x ≡ xI.e., it tells us that x is equal to itself. Not very insightful! Intuitively, this makes sense: if all we know about x is that it is an integer, we cannot tell anything about its value.

**TOOLING.** * Many of the examples in this blog post (though sadly not all) can also be auto-derived by one of two tools. On the #haskell IRC channel we can ask lambdabot to derive free theorems for any types not involving type classes or type constructor classes. If you ask*

*@free x :: Int*

lambdabot will reply with

x = x(I recommend starting a private conversation with lambdabot so you avoid spamming the whole #haskell channel.)

Alternatively, you can also try the online free theorem generator. This free theorem generator is a bit more precise than lambdabot (which takes some shortcuts sometimes), and supports type classes, but cannot work with type constructors (lambdabot can work with unknown type constructors but not with quantification over type constructors, unfortunately). FunctionsFor functions we map related arguments to related results:

f ℛ(A -> B) f' iff forall x, x'. if x ℛ(A) x' then f x ℛ(B) f' x'(The types of x and x' here depend on what precisely A is; see *The type of ℛ*, below.)

Example. Suppose f :: Int -> Bool. By parametricity

f ℛ(Int -> Bool) f iff forall x :: Int, x' :: Int. if x ℛ(Int) x' then f x ℛ(Bool) f x' -- both Int and Bool are constant types iff forall x :: Int, x' :: Int. if x ≡ x' then f x ≡ f x' -- simplify iff f ≡ fAgain, not very informative. Parametricity doesn’t tell us anything about functions between constant types. Time to look at something more interesting!

Polymorphism (over types of kind *)The definition for polymorphic values is

f ℛ(∀a. t) f' iff forall A, A', a :: A ⇔ A'. f@A ℛ(t) f'@A' -- where 'a' can occur free in tThat is, whenever we pick two types A and A', and *some* relation a between A and A', the function f@A obtained by instantiating the type variable by A must be related to the function f'@A' obtained by instantiating the type variable by A'. In what follows we will write explicit type instantiation like this only if the type is not clear from the context; specifically, we will omit it when we supply arguments to the function.

**The type of ℛ.**

∀ab. a -> b -> a is an example of a *closed* type: all type variables are bound by a universal quantifier. An *open* type is a type with free type variables such as ∀b. a -> b -> a or even a -> b -> a. (Note that this distinction is harder to see in Haskell where universal quantifiers are often implicit. We will not follow that convention in this article.)

We said in the introduction that if t is a closed type, ℛ(t) relates two terms of type t. As we saw, in order to be able to give a meaning to *open* types we need a mapping from any free variable a to a relation a :: A ⇔ A'. In this article we somewhat informally maintain this mapping simply by using the same name for the type variable and the relation.

The interpretation of ℛ for a free type variable a is defined in terms of the corresponding relation:

x ℛ(a) x' -- the type variable iff (x, x') ∈ a -- the relation Example: ∀a. a -> aLet’s consider a number of examples, starting with an f :: ∀a. a -> a:

f ℛ(∀a. a -> a) f -- parametricity iff forall A, A', a :: A ⇔ A'. f@A ℛ(a -> a) f@A' -- definition for function types iff forall A, A', a :: A ⇔ A', x :: A, x' :: A'. if x ℛ(a) x' then f x ℛ(a) f x'It might not be immediately evident from the last line what this actually allows us to conclude about f, so let’s look at this a little closer. A function g is a special kind of relation, relating any argument x to g x; since the property holds for any kind of relation a : A ⇔ A', it must also hold for a *function* a⃯ :: A -> A':

We can apply this result to show that any f :: ∀a. a -> a must be the identity function: picking a⃯ = const x, we get const x (f x) ≡ f (const x x), i.e. x ≡ f x, as required.

**NOTE**.

*We are doing fast and loose reasoning in this tutorial and will completely ignore any totality issues. See Automatically Generating Counterexamples to Naive Free Theorems, or the associated web interface, for some insights about what wrong conclusions we can draw by ignoring totality.*Example: ∀a. a -> a -> a

Intuitively, there are only two things a function f :: ∀a. a -> a -> a can do: it can either return its first argument, or it can return its second argument. What does parametricity tell us? Let’s see:

f ℛ(∀a. a -> a -> a) f iff forall A, A', a :: A ⇔ A'. f@A ℛ(a -> a -> a) f@A' -- applying the rule for functions twice iff forall A, A', a :: A ⇔ A', x :: A, x' :: A', y :: A, y' :: A'. if x ℛ(a) x', y ℛ(a) y' then f x y ℛ(a) f x' y'Let’s again specialize the last line to pick a function a⃯ :: A -> A' for the relation a:

forall x :: A, x' :: A', y :: A, y' :: A'. if x ℛ(a⃯) x', y ℛ(a⃯) y' then f x y ℛ(a⃯) f x' y' -- a⃯ is a function iff forall x :: A, y :: A. if a⃯ x ≡ x' and a⃯ y ≡ y' then a⃯ (f x y) ≡ f x' y' -- simplify iff a⃯ (f x y) = f (a⃯ x) (a⃯ y)So parametricity allows us to “push in” or “distribute” a⃯ over f. The fact that f must either return its first or its second argument follows from parametricity, but not in a completely obvious way; see the reddit thread How to use free theorems.

Example: ∀ab. a -> bOther than undefined (which we are ignoring), there can be no function f :: ∀ab. a -> b. Let’s suppose that one *did* exist; what does parametricity tell us?

Picking two functions a⃯ :: A -> A' and b⃯ :: B -> B' for a and b, we get

b⃯ . f = f . a⃯It’s not too difficult to derive contradiction from this (remember that you can pick any two functions a⃯ and b⃯ between any types of your choosing). Hence, such a function cannot exist.

Example: ∀ab. (a -> b) -> a -> bThe only thing a function of this type can do is apply the supplied function to the supplied argument (alternatively, if you prefer, this must be the identity function). Let’s spell this example out in a bit of detail because it is our first example of a higher order function.

f ℛ(∀ab. (a -> b) -> a -> b) f -- apply rule for polymorphism, twice iff forall A, A', B, B', a :: A ⇔ A', b :: B ⇔ B'. f@A,B ℛ((a -> b) -> a -> b) f@A',B' -- apply rule for functions, twice iff forall A, A', B, B', a :: A ⇔ A', b :: B ⇔ B'. forall g :: A -> B, g' :: A' -> B', x :: A, x' :: A'. if g ℛ(a -> b) g' and x ℛ(a) x' then f g x ℛ(b) f g' x'Let’s expand what that premise g ℛ(a -> b) g' means:

g ℛ(a -> b) g' iff forall y :: A, y' :: A'. if y ℛ(a) y' then g y ℛ(b) g' y'For the special case that we pick *functions* a⃯ :: A -> A' and b⃯ :: B -> B' for a and b, that premise collapses to

So that the free theorem for f :: ∀ab. (a -> b) -> a -> b becomes

if b⃯ . g ≡ g' . a⃯ then b⃯ . f g ≡ f g' . a⃯Picking b⃯ = const g, g' = g, and a⃯ = id (verify that the premise holds) we get that indeed g ≡ f g, as expected.

**Useful shortcut.** This pattern is worth remembering:

A function f :: ∀ab. (∀c. c -> String) -> a -> b -> String is not only higher order, but has a rank-2 type: it insists that the function it is given is *itself* polymorphic. This makes it possible to write, for example

Note that since x and y have different types, it is important that g is polymorphic. What is the free theorem for f?

f ℛ(∀ab. (∀c. c -> String) -> a -> b -> String) f -- apply rule for polymorphism, twice iff forall A, A', B, B', a :: A ⇔ A', b :: B ⇔ B'. f ℛ((∀c. c -> String) -> a -> b -> String) f -- apply rule for functions three times, and simplify ℛ(String) to (≡) iff forall A, A', B, B', a :: A ⇔ A', b :: B ⇔ B'. forall g :: ∀c. c -> String, g' :: ∀c. c -> String. forall x :: A, x' :: A', y :: B, y' :: B'. if g ℛ(∀c. c -> String) g', x ℛ(a) x', y ℛ(b) y' then f g x y ≡ f g' x' y'Specializing this theorem to *functions* a⃯ :: A -> A' and b⃯ :: B -> B' we get

But that is somewhat surprising, because it seems to say that the values of x and y cannot matter at all! What is going on? Expanding the first premise:

g ℛ(∀c. c -> String) g' iff forall C, C', c :: C ⇔ C', g ℛ(c -> String) g' iff forall C, C', c :: C ⇔ C', z :: C, z' :: C'. if z ℛ(c) z' then g z = g' z'Let’s stop for a moment to ponder what this requirement for g and g' really says: given *any* relation c, and *any* elements z and z' that are related by c—in other words, for any z and z' at all—we must have that g z and g' z' give us equal results. This means that g and g' must be constant functions, and the *same* constant function at that. As a consequence, for any function f of the above type, f g must itself be constant in x and y. In part two we will see a more useful variation which uses the Show type class.

Incidentally, note that this quantification over an arbitrary relation c is a *premise* to the free theorem, not a conclusion; hence we cannot simply choose to consider only *functions* c.

**TOOLING.** * Indeed, if you enter*

*(forall c. c -> String) -> a -> b -> String in the online free theorem generator you will see that it first gives the free theorem using relations only, and then says it will reduce all “permissible” relation variables to functions; in this example, that is all relations except for c; lambdabot doesn’t make this distinction and*To be continued

*always*reduces relations to functions, which is not correct.In part 2 (to be published shortly) we will cover type constructors, type classes and type constructor classes. Meanwhile, here are some links to papers on the subject if you want to read more.

- Theorems for free! by Philip Wadler is the seminal paper on the topic. It doesn’t however cover general type classes, higher types, or type constructors.
- Type-safe cast does no harm: Syntactic parametricity for Fω and beyond by Dimitrios Vytiniotis and Stephanie Weirich is a more theoretical paper about free theorems in a calculus with higher rank types and representation types.