News aggregator

Increasing Haskell modularity

haskell-cafe - Wed, 10/01/2014 - 2:14pm
Dear Café, Edward Yang recently wrote about the non-modularity of the current semantics for typeclasses[0] and open type families[1]. Given these problems, we can either try to work around the problem, or decide whether these features are worth the problems. The specific pair of proposals I am making are the following: * Give up on global uniqueness of typeclass instances. Oleg discusses adding local typclass instances without losing coherence in his reflection paper[2]. If we adopt his proposal, and weaken global uniqueness of instances to local uniqueness, we can then say that typeclass instances in a module are considered more local than imported instances, and therefore override them. Since instances will be locally unique, we don't have to pass around dictionaries. Data types that expect globally unique instances, such as Set, will have to store dictionaries, however. * Give up on non-associated open type families. This I have researched less well, but it seems to me tha
Categories: Offsite Discussion

Functional Jobs: Full Stack Functional Web Engineer at Front Row Education (Full-time)

Planet Haskell - Wed, 10/01/2014 - 1:17pm

Front Row Education ( - San Francisco, Fulltime

== Position ==

Early Full-stack web engineer to join fast-growing education startup that changes how hundreds of thousands of kids learn math.

== TL;DR - Reasons to care about working with Front Row ==

  • A mission you can be proud of: kids using Front Row improve twice as much at math

  • Tremendous impact on a small team

  • Flexibility on what you work on, and autonomy over your schedule

  • Effective & exciting tools: Clojure, Haskell, PostgreSQL, Backbone.js, Ansible

  • Be part of a growing success: in just over a year after launch, we are in more than 6% of all US schools

== The Business ==

Millions of teachers around the USA are struggling to help 30+ students in their class learn math because every student is in their own place. In a typical fourth grade classroom, there may be students learning to count, students learning to add, students learning to multiply, and students learning how exponents work - and one teacher somehow needs to address all these needs.

Thousands of teachers use Front Row every day to save hours of time and make sure their students are growing quickly. Front Row active users have been growing 100% a month for the past 8 school months.

== The Role ==

As one of our very first engineers, you will be part of a team of developers who are passionate about their vocation, take pride in their craft and who push each other to grow as professionals. You will strive for pragmatism and 80/20 in your work. You will be using tools that provide you with the most leverage and make you most effective. By working really smart, you will produce more than the average developer ever will, but without the crazy hours.

You will work in an effective team that plans, executes and reflects together. Because we’re a small team, everything you create will go into production and be used by students. You will never do unimportant work: every contribution will make a clear and tangible impact on the company’s trajectory. Your personal success will be directly aligned with that of the company.

Most importantly, your work will have purpose: Front Row is a mission-driven company that takes pride in making a significant impact in the lives of hundreds of thousands of students.

== Benefits ==

  • Competitive salary

  • Generous equity option grants

  • Medical, Dental, and Vision

  • Food budget

  • Work from home up to 1 day a week, extremely flexible work schedule

  • Team meal outing every week, and half-day event every month (trip to Sonoma, BBQ, etc)

  • Equipment budget

  • Flexible, untracked vacation day policy

  • Working from Runway - one of the best startup coworking locations right in the heart of San Francisco

Get information on how to apply for this position.

Categories: Offsite Blogs

Journal of Functional Programming: Call for PhD Abstracts

Haskell on Reddit - Wed, 10/01/2014 - 11:15am

The abstracts of recently completed PhDs in functional programming can be published in the Journal of Functional Programming. Simple process, please advertise widely!

submitted by grahamhutton
[link] [2 comments]
Categories: Incoming News

Monad examples

Haskell on Reddit - Wed, 10/01/2014 - 10:18am
Categories: Incoming News

Functional Jobs: Senior Software Engineer at McGraw-Hill Education (Full-time)

Planet Haskell - Wed, 10/01/2014 - 10:07am

This Senior Software Engineer position is with the new LearnSmart team at McGraw-Hill Education's new and growing Research & Development center in Boston's Innovation District.

We make software that helps college students study smarter, earn better grades, and retain more knowledge.

The LearnSmart adaptive engine powers the products in our LearnSmart Advantage suite — LearnSmart, SmartBook, LearnSmart Achieve, LearnSmart Prep, and LearnSmart Labs. These products provide a personalized learning path that continuously adapts course content based on a student’s current knowledge and confidence level.

On our team, you'll get to:

  • Move textbooks and learning into the digital era
  • Create software used by millions of students
  • Advance the state of the art in adaptive learning technology
  • Make a real difference in education

Our team's products are built with Flow, a functional language in the ML family. Flow lets us write code once and deliver it to students on multiple platforms and device types. Other languages in our development ecosystem include especially JavaScript, but also C++, SWF (Flash), and Haxe.

If you're interested in functional languages like Scala, Swift, Erlang, Clojure, F#, Lisp, Haskell, and OCaml, then you'll enjoy learning Flow. We don't require that you have previous experience with functional programming, only enthusiasm for learning it. But if you have do some experience with functional languages, so much the better! (On-the-job experience is best, but coursework, personal projects, and open-source contributions count too.)

We require only that you:

  • Have a solid grasp of CS fundamentals (languages, algorithms, and data structures)
  • Be comfortable moving between multiple programming languages
  • Be comfortable with modern software practices: version control (Git), test-driven development, continuous integration, Agile

Get information on how to apply for this position.

Categories: Offsite Blogs

Lambdaheads - Wed 8.10.2014 - Functional Programming Vienna

Haskell on Reddit - Wed, 10/01/2014 - 9:50am

Friends of the Functional!

The λheads will be meeting at 19:30 in the Metalab library (Rathausstraße 6, 1010 Wien) as usual.

This time we have a presentation on Swift. And if I have enough time I will present on my current Haskell project.

Hope you are interested in coming. Yours Martin (ε/2)

submitted by epsilonhalbe
[link] [1 comment]
Categories: Incoming News

cabal install sometimes want to download dependencies

Haskell on Reddit - Wed, 10/01/2014 - 9:23am

Here's something that makes no sense to me. Sometimes after I've run cabal configure and cabal build and everything worked, I got to run cabal install and it wants to download and build some new dependencies -- even though the library I'm installing is already fully built.

Why would this happen?

submitted by singpolyma
[link] [comment]
Categories: Incoming News

Dijkstra monads

Haskell on Reddit - Wed, 10/01/2014 - 8:56am
Categories: Incoming News

Can anyone help me out?

Haskell on Reddit - Wed, 10/01/2014 - 7:26am

I'm doing a tutorial exercise for my functional programming course. I'm not entirely sure how to code this...

  1. (a) Write a function inRange :: Int -> Int -> [Int] -> [Int] to return all numbers in the input list within the range given by the first two arguments (inclusive). For example, inRange 5 10 [1..15] == [5,6,7,8,9,10] Your definition should use a list comprehension, not recursion. (b) Write an equivalent function inRangeRec, using recursion. (c) To confirm the two functions are equivalent, write a test function prop_inRange and run the appropriate QuickCheck test.

An explanation would be awesome. Thank you! :)

submitted by el_rais
[link] [11 comments]
Categories: Incoming News

Neil Mitchell: Why Traversable/Foldable should not be in the Prelude

Planet Haskell - Wed, 10/01/2014 - 6:02am

Summary: For GHC 7.10, Traversable and Foldable are going to be in the Prelude. I missed the original discussion, but I suspect it's a bad idea.

Types are how Haskell programmers communicate their intentions to each other. Currently, the Haskell Prelude contains:

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

As of GHC 7.10, as part of something known as the Burning Bridges Proposal (ticket, discussion, I can't actually find a full proposal...), that will become:

mapM :: (Traversable t, Monad m) => (a -> m b) -> t a -> m (t b)

Surely that's a good thing? Aren't more general types always better? Isn't the Prelude an archaic beast from the time before? I'd argue functions which are highly polymorphic are hard to use, and hard to think about, especially for beginners. I'd also argue the Prelude is remarkably well designed, not perfect, but quite an impressive feat.

What makes a type signature complex?

I've been thinking recently about what makes type signatures complex, both to practitioners, and to relative beginners. My rough metric is:

  • Fully concrete types are usually simple, as long as they aren't too long. The longer a type gets, the more complex it gets.
  • Types with functions in them aren't too bad (order-1 types), but as you go up to order-2 types things start to get more complex.
  • Fully polymorphic functions can be simpler than concrete functions, since they declare what you don't need to worry about.
  • Functions with type classes are more complex, since you need to read the type signature while looking at the context, and need to know each class being used.
  • Simple type classes (Eq, Show) aren't too bad, but custom type classes impose more of a burden.
  • As you add more type classes, the complexity grows faster than linearly. Three type classes are not three times as complex as one, but quite a bit harder.
  • Higher kinded type classes are significantly more complex than kind * type classes, e.g. Monad, Functor. The reason is that instead of having a hole you fill in, you now have a hole which itself has a hole.
  • The higher-kinded type classes Monad and Functor aren't as bad as the others, since Functor is really the "simplest" higher-kinded type class, and Monad is required knowledge for IO.
  • As you have more higher kinded type classes, the complexity burden grows even worse than for kind * type classes. Two is significantly more complex than one.

By that metric, the old mapM isn't too bad, but the new mapM is quite complex. It has two higher-kinded type classes, and one of them is not one of the common ones. I appreciate that making Foldable and Traversable key to Haskell will probably lead to them being more used, but now all beginners are going to have to wade through the Monad tutorial, their Foldable tutorial and their Traversable tutorial before they start programming (or just give up).

Why generality hurts

There are two main reasons why generality hurts:

Reading type signatures becomes difficult/impossible. We already have that problem with the Control.Arrow module, which (as far as most people use it), is just a pile of tuple combinators. But unlike other tuple combinators, these are ones whose type signature can't be understood. When I want to use &&& or *** I just pick randomly, see if it type checks, then try again. When other people I know what to use these functions they just use an explicit lambda. No one thinks of referring to the documentation, since the documentation presents a unification problem (which most of the people I know could solve), not an intuition.

Reading code becomes difficult. Haskell is brilliant for letting you write a composable pipeline of code that takes some input, does some processing, and produces some output. But that only works if you have enough concrete pieces in each function to read each piece in isolation. As an example:

test = foo . mapM baz . bar

Using the current mapM definition I can, in a fraction of a second, know the approximate shape of what foo consumes, and what bar produces. With the new mapM I don't, and have to keep more context in my head to reason about the code.

Who it hurts

Generality of this nature tends to hurt two types of people:

Beginners are hurt because they need to know more concepts just to get going. As a beginner I read through Data.List regularly to build up weapons in my arsenal to attack larger problems. The new Data.List will be generalised, and reading it won't give the insights I enjoyed. Maybe the beginner can instantiate all Foldable things to [], but that adds a mental burden to exactly those people who can bear it least.

Practitioners, those who are paid to code for a living, will have greater problems with maintenance. This isn't an unsubstantiated guess... I have taken over a project which made extensive use of the generalised traverse and sequence functions. Yes, the code was concise, but it was read-only, and even then, required me to "trust" that the compiler and libraries snapped together properly.

Who it benefits

The benefit probably comes from those who are already using the Applicative/Traversable classes regularly. For these people, they can probably avoid an import Prelude(). I am not against ever changing the Prelude, but I do think that for changes of this magnitude the ideas should probably be prototyped as a separate package, widely accepted, and only then should significant surgery be attempted on the Prelude. The classy-prelude work has gone in that direction, and I wish them luck, but the significant changes they've already iterated through suggest the design space is quite large.

Concluding remarks

I realise that I got to this discussion late, perhaps too late to expect my viewpoint to count. But I'd like to leave by reproducing Henning Thielemann's email on the subject:

David Luposchainsky wrote:

+1. I think the Prelude should be a general module of the most commonly
needed functions, which (generalized) folds and traversals are certainly
part of; right now it feels more like a beginner module at times.

It is certainly a kind of beginner module, but that's good. Experts know
how to import. Putting the most general functions into Prelude does not
work because:

1. There are often multiple sensible generalizations of a Prelude

2. You have to add more type annotations since types cannot be infered
from the functions.

There is simply no need to change Prelude and all packages that rely on
specific types. Just don't be lazy and import the stuff you need!

I should change my vote to:


Categories: Offsite Blogs

Ship You a Haskell - Wed, 10/01/2014 - 5:44am
Categories: Offsite Blogs

is hackage down again?

Haskell on Reddit - Wed, 10/01/2014 - 4:58am

seems dead with 504s

edit: it's definitely back up now, nvm

submitted by Intolerable
[link] [3 comments]
Categories: Incoming News