# News aggregator

### Closed Type Families: separate instance groups?

### Why can QuasiQuoters only be used to generate top-level declarations?

There's probably a good reason, but it bugs me that this is valid:

[qq| thing :: Custom -> DSL |] thing = ......while this is not:

other = thing where [qq| thing :: Custom -> DSL |] thing = ......but this is:

other = thing where thing :: [qq| Custom -> DSL |] thing = ...(Originally posted to /r/haskellquestions, but this didn't get any responses there so I thought I'd try the bigger subreddit.)

submitted by spindakin[link] [10 comments]

### What is the difference between an Algebraic Data Type and an Abstract Data Type?

I am struggling to understand the difference between those two concepts. To me they look pretty much the same, AlgDT allow type composition but so do AbsDT right?

For example I can compose ints and chars in an abstract data type:

struct coordinates { int x; int y; char data_point_name[5]; };One powerful feature of AlgDT that really impressed was that I was able to define the set of natural numbers recursively:

data Nat = Z | S Natwhere Z is 0 and S the successor function. That is something that I could not do using 'struct' but does it make the different between AlgDTs and AbsDTs a fundamental one?

I know that I am confusing something and that there is a flaw in my understanding but I don't know what! Thank you for reading.

submitted by fictiveaaron[link] [42 comments]

### Proposal: Shorter Import Syntax

### haskellers' view of closures? How is this stuff an improvement on OOP?

Touring around other languages like javascript, some of these functional-ish languages seem to make a big deal of closures as part of the functional paradigm.

To me it looks like OOP by another name - passing state and associated method around as a bundle. In fact, I think in the C++ world, STL took pains to characterize lambdas+captures as "stamping out classes" and not "anonymous functions".

The only thing that's slightly better than vanilla OOP is that it seems to default to a many-1 data to function coupling, whereas with OOP you have many-to-many data to function coupling. All in all closures feel a bit like OOP-in-sheep's clothing.

How do haskellers view closures? Maybe there's a win that I'm selling short here?

submitted by klaxion[link] [36 comments]

### Magnus Therning: Oh no! Success

This can’t possibly be good for Haskell…

We chose Haskell and the FP Complete stack because we knew the complexity of the problem required a new approach. The result was that we built better software faster than ever, and delivered it defect-free into a production environment where it has proven robust and high-performance

### Haskell success story mentioned in press release from OTAS Technology, a market analysis company.

### Brent Yorgey: Crystal Ball Connection Patterns via Species and Generating Functions

A couple weeks ago, Denise posted Puzzle: Crystal Ball Connection Patterns on her blog, Let’s Play Math. I had fun playing with it and thought I would demonstrate how to apply some high-powered combinatorial techniques to it (probably not what Denise had in mind!).

The setup is that there are (distinct) friends who can talk to each other on the phone. Only two people can talk at a time (no conference calls). The question is to determine how many different “configurations” there are. Not everyone has to talk, so a configuration consists of some subset of the friends arranged in (unordered) conversational pairs.

*Warning: spoilers ahead*! If you’d like to play around with this yourself (and it is indeed a nice, accessible combinatorics problem to play with), stop reading now. My goal in this post is to have fun applying some advanced tools to this (relatively) simple problem.

Let’s start by visualizing some configurations. In her post, Denise illustrated the complete set of configurations for , which I will visualize like this:

Notice how I’ve arranged them: in the first row is the unique configuration where no one is talking (yes, that counts). In the second row are the six possible configurations with just a single conversation. The last row has the three possible configurations with two conversations.

One good approach at this point would be to derive some recurrences. This problem does indeed admit a nice recurrence, but I will let you ponder it. Instead, let’s see if we can just “brute-force” our way to a general formula, using our combinatorial wits. Later I will demonstrate a much more principled, mechanical way to *derive* a general formula.

Let’s start by coming up with a formula for , the number of configurations with people and conversations. The number of ways of choosing pairs out of a total of is the multinomial coefficient . However, that overcounts things: it actually distinguishes the first pair, second pair, and so on, but we don’t want to have any ordering on the pairs. So we have to divide by , the number of distinct orderings of the pairs. Thus,

Let’s do a few sanity checks. First, when , we have . We can also try some other small numbers we’ve already enumerated by hand: for example, , and . So this seems to work.

For people, there can be at most conversations. So, the total number of configurations is going to be

.

We can use this to compute for the first few values of :

At this point we could look up the sequence 1,1,2,4,10,26,76 on the OEIS and find out all sorts of fun things: *e.g.* that we are also counting self-inverse permutations, *i.e.* involutions, that these numbers are also called “restricted Stirling numbers of the second kind”, some recurrence relations, *etc.*, as well as enough references to keep us busy reading for a whole year.

We can describe configurations as elements of the combinatorial species . That is, a configuration is an unordered set () of () things (), where each thing can either be an unordered pair () of people talking on the phone, or () a single person () who is not talking.

We can now use the Haskell species library to automatically generate some counts and see whether they agree with our manual enumerations. First, some boilerplate setup:

ghci> :set -XNoImplicitPrelude ghci> :m +NumericPrelude ghci> :m +Math.Combinatorics.SpeciesNow we define the species of configurations:

ghci> let configurations = set `o` (set `ofSizeExactly` 2 + singleton)We can ask the library to count the number of configurations for different :

ghci> take 10 (labelled configurations) [1,1,2,4,10,26,76,232,764,2620]Oh good, those numbers look familiar! Now, I wonder how many configurations there are for ?

ghci> labelled configurations !! 100 24053347438333478953622433243028232812964119825419485684849162710512551427284402176Yikes!

We can also use the library to generate exhaustive lists of configurations, and draw them using diagrams. For example, here are all configurations for . (If you want to see the code used to generate this diagram, you can find it here.)

And just for fun, let’s draw all configurations for :

Whee!

A general formula, via generating functionsFinally, I want to show how to use the species definition given above and the theory of generating functions to (somewhat) mechanically *derive* a general formula for the number of configurations. (Hopefully it will end up being equivalent to the formula we came up with near the beginning of the post!) Of course, this is also what the species library is doing, but only numerically—we will do things *symbolically*.

First, note that we are counting labelled configurations (the friends are all distinct), so we want to consider exponential generating functions (egfs). Recall that the egf for a species is given by

,

that is, a (possibly infinite) formal power series where the coefficient of is the number of distinct labelled -structures of size . In our case, we need

,

since there is exactly one set structure of any size, and

,

which is just the restriction of to only the term. Of course, we also have . Putting this together, we calculate

Ultimately, we want something of the form , so we’ll need to collect up like powers of . To do that, we can do a bit of reindexing. Right now, the double sum is adding up a bunch of terms that can be thought of as making a triangle:

Each ordered pair in the triangle corresponds to a single term being added. Each column corresponds to a particular value of , with increasing to the right. Within each column, goes from up to .

The powers of in our double sum are given by . If we draw in lines showing terms that have the same power of , it looks like this:

So let’s choose a new variable , defined by . We can see that we will have terms for every . We will also keep the variable for our other index, and substitute to get rid of . In other words, instead of adding up the triangle by columns, we are going to add it up by diagonals.

Previously we had ; substituting for that now turns into . Adding to both sides and dividing by yields (we can round down since is an integer). Looking at the diagram above, this makes sense: the height of each diagonal line is indeed half its index. Rewriting our indices of summation and substituting for , we now have:

And hey, look at that! The coefficient of is exactly what we previously came up with for . Math works!

### Haskell source-browsing nirvana?

I'm using an awkward mix of hasktags, dash and hoogle. I wonder if anyone has achieved my dream in any editor: It would work like hasktags except it could use context like imports and qualifications to find the correct definition, jumping across the project source into sources for installed packages including ghc base.

submitted by rdfox[link] [6 comments]

### mightybyte: The Problem with Curation

Recently I received a question from a user asking about "cabal hell" when installing one of my packages. The scenario in question worked fine for us, but for some reason it wasn't working for the user. When users report problems like this they usually do not provide enough information for us to solve it. So then we begin the sometimes arduous back and forth process of gathering the information we need to diagnose the problem and suggest a workaround or implement a fix.

In this particular case luck was on our side and the user's second message just happened to include the key piece of information. The problem in this case was that they were using stackage instead of the normal hackage build that people usually use. Using stackage locks down your dependency bounds to a single version. The user reporting the problem was trying to add additional dependencies to his project and those dependencies required different versions. Stackage was taking away degrees of freedom from the dependency solver (demoting it from the driver seat to the passenger seat). Fortunately in this case the fix was simple: stop freezing down versions with stackage. As soon as the user did that it worked fine.

This highlights the core problem with package curation: it is based on a closed-world assumption. I think that this makes it not a viable answer to the general question of how to solve the package dependency problem. The world that many users will encounter is not closed. People are constantly creating new packages. Curation resources are finite and trying to keep up with the world is a losing battle. Also, even if we had infinite curation resources and zero delay between the creation of a package and its inclusion in the curated repository, that would still not be good enough. There are many people working with code that is not public and therefore cannot be curated. We need a more general solution to the problem that doesn't require a curator.

### Haskell dev role in Strats at Standard Chartered(Singapore)

### Pixel by pixel image processing

### -prof, -threaded, and -N

### Don Stewart (dons): Haskell dev role in Strats at Standard Chartered [Singapore]

The Strats team at Standard Chartered has an open position for a typed functional programming developer, based in Singapore.

You will work on the trading floor, directly with traders, building software to automate their work and improve their efficiency. The role is highly development focused and you will use Haskell for almost all tasks: data analysis, market data publishing, database access, web services, desktop GUIs, large parallel tasks, quantitative models, solvers, everything. This is a fast paced role – code you write today will be deployed within hours to hundreds of users and has to work.

This is a permanent position in Singapore as part of the Strats global team. Demonstrated experience in typed FP (Haskell, OCaml, F# etc) is required. We have around 2.5 million lines of Haskell, and our own Haskell compiler. In this context we look for skill and taste in typed functional programming to capture and abstract over complex, messy systems.

Experience writing typed APIs to external systems such as databases, web services, pub/sub platforms is very desirable. We like working code, so if you have Hackage or github libraries, we definitely want to see them. We also like StackOverflow answers, blog posts, academic papers, or other arenas where you can show broad FP ability. A PhD in computer science is a strong advantage.

The role requires physical presence on the trading floor in Singapore. Remote work is not an option. Ideally you have some project and client management skills — you will talk to users, understand their problems and then implement and deliver what they really need. No financial background is required.

More info about our development process is in the 2012 PADL keynote, and a 2013 HaskellCast interview.

If this sounds exciting to you, please send your resume to me – donald.stewart <at> sc.com.

Role posted 2015-06-03

Tagged: jobs