Well, 2016 … that just happened. About the only thing I can put in perspective at closing of this year is progress and innovation in Haskell ecosystem. There was a lot inspiring work and progress that pushed the state of the art forward.

This was a monumental year of Haskell in production. There were dozens of talks given about success stories with an unprecedented amount of commercially funded work from small startups to international banks. Several very honest accounts of the good and the bad were published, which gave us a rare glimpse into what it takes to plant Haskell in a corporate environment and foster it’s growth.
…

If you are at all interested in Haskell and/or functional programming, don’t miss this collection of comments and links. It will save you hours of surfing, looking for equivalent content.

To learn quantum mechanics, one must become adept in the use of various mathematical structures that make up the theory; one must also become familiar with some basic laboratory experiments that the theory is designed to explain. The laboratory ideas are naturally expressed in one language, and the theoretical ideas in another. We present a method for learning quantum mechanics that begins with a laboratory language for the description and simulation of simple but essential laboratory experiments, so that students can gain some intuition about the phenomena that a theory of quantum mechanics needs to explain. Then, in parallel with the introduction of the mathematical framework on which quantum mechanics is based, we introduce a calculational language for describing important mathematical objects and operations, allowing students to do calculations in quantum mechanics, including calculations that cannot be done by hand. Finally, we ask students to use the calculational language to implement a simplified version of the laboratory language, bringing together the theoretical and laboratory ideas.

You won’t find a quantum computer under your Christmas tree this year.

But Haskell + Walck will teach you the basics of quantum mechanics.

You will have to search for it but “Gerald Jay Sussman & Jack Wisdom (2013): Functional Differential Geometry. The MIT Press.” is out on the net somewhere.

Very tough sledding but this snippet from the preface may tempt you into buying a copy:

…
But the single biggest difference between our treatment and others is that we integrate computer programming into our explanations. By programming a computer to interpret our formulas we soon learn whether or not a formula is correct. If a formula is not clear, it will not be interpretable. If it is wrong, we will get a wrong answer. In either case we are led to improve our program and as a result improve our understanding. We have been teaching advanced classical mechanics at MIT for many years using this strategy. We use precise functional notation and we have students program in a functional language. The students enjoy this approach and we have learned a lot ourselves. It is the experience of writing software for expressing the mathematical content and the insights that we gain from doing it that we feel is revolutionary. We want others to have a similar experience.
…

It turns out that much of Haskell can be understood through a branch of mathematics called Category Theory. Concepts such as Functor, Adjoints, Monads and others all have a basis in the Category Theory. In this talk, basic categorical concepts, starting with categories and building through functors, natural transformations, and universality, will be introduced. To illustrate these, some mathematical concepts such as homology and homotopy, monoids and groups will be discussed as well (proofs omitted).

This paper describes the language DIMPL, a domain-specific language (DSL) for discrete mathematics. Based on Haskell, DIMPL carries all the advantages of a purely functional programming language. Besides containing a comprehensive library of types and efficient functions covering the areas of logic, set theory, combinatorics, graph theory, number theory and algebra, the DSL also has a notation akin to one used in these fields of study. This paper also demonstrates the benefits of DIMPL by comparing it with C, Fortran, MATLAB and Python &emdash; languages that are commonly used in mathematical programming.

From the comparison, solving simultaneous linear equations:

Much more is promised in the future for DIMPL:

Future versions of DIMPL will have an extended library comprising of modules for lattices, groups, rings, monoids and other discrete structures. They will also contain additional functions for the existing modules such as Graph and Tree. Moreover, incorporating Haskell’s support for pure parallelism and explicit concurrency in the library functions could significantly improve the efficiency of some functions on multi-core machines.

Can you guess the one thing that Ronit left out of his paper?

At this point, @SwiftLang is probably a better, and more valuable, vehicle for learning functional programming than Haskell.

Given Erik’s deep experience and knowledge of functional programming, such a tweet has to give you pause.

Less daunting was the “67 retweets 56 favorites” by the known users of SwiftLang. 😉

A more accurate statement would be:

At this point, @SwiftLang is probably a better, and more valuable, vehicle for learning functional programming than Haskell, if you program for iOS, OS X, and watchOS.

In this post I will describe the current state of the Haskell ecosystem to the best of my knowledge and its suitability for various programming domains and tasks. The purpose of this post is to discuss both the good and the bad by advertising where Haskell shines while highlighting where I believe there is room for improvement.

This post is grouped into two sections: the first section covers Haskell’s suitability for particular programming application domains (i.e. servers, games, or data science) and the second section covers Haskell’s suitability for common general-purpose programming needs (such as testing, IDEs, or concurrency).

The topics are roughly sorted from greatest strengths to greatest weaknesses. Each programming area will also be summarized by a single rating of either:

Best in class: the best experience in any language

Mature: suitable for most programmers

Immature: only acceptable for early-adopters

Bad: pretty unusable

The more positive the rating the more I will support the rating with success stories in the wild. The more negative the rating the more I will offer constructive advice for how to improve things.
…

There is nothing that provokes discussion more than a listing of items with quality rankings!

How cool is that?! You can get the “big” file or individual files. Well, I don’t see “computer science” listed as a separate file so I assume that would require downloading the “big” file.

Rather than a “worth mentioning” FAQ you could have a “frequently” mentioned based FAQ for a large number of areas.

The further you move away from the dump date, the less accurate your “frequency,” and I don’t know how much of an impact that would have.

Still, has a great deal of promise!

Posted in Functional Programming, Haskell | Comments Off on Frequently brought up topics in #haskell [Do you have a frequency-based FAQ?]

NOTE
– This is not an official document by the ghc development team.
– Please don’t forget “semantics”. It’s very important.
– This is written for ghc 7.8 (and ghc 7.10).

As the weekend approaches I thought you might enjoy the discipline of getting a bit closer to the metal than usual. 😉

We describe a method for deepening a student’s understanding of basic physics by asking the student to express physical ideas in a functional programming language. The method is implemented in a second-year course in computational physics at Lebanon Valley College. We argue that the structure of Newtonian mechanics is clarified by its expression in a language (Haskell) that supports higher-order functions, types, and type classes. In electromagnetic theory, the type signatures of functions that calculate electric and magnetic fields clearly express the functional dependency on the charge and current distributions that produce the fields. Many of the ideas in basic physics are well-captured by a type or a function.

A nice combination of two subjects of academic importance!

Great slides on category theory with this quote on slide 6:

One of the goal of Category Theory is to create a homogeneous vocabulary between different disciplines.

Is the creation of a homogeneous vocabulary responsible for the complexity of category theory or is the proof of equivalence between different disciplines?

As you know, topic maps retains the vocabularies of different disciplines as opposed to replacing them with a homogeneous one. Nor do topic maps require proof of equivalence in the sense of category theory.

We study some of the applications of category theory to functional programming, particularly in the context of the Haskell functional programming language, and the Agda dependently typed functional programming language and proof assistant. More specifically, we describe and explain the concepts of category theory needed for conceptualizing and better understanding algebraic data types and folds, functors, monads, and parametrically polymorphic functions. With this purpose, we give a detailed account of categories, functors and endofunctors, natural transformations, monads and Kleisli triples, algebras and initial algebras over endofunctors, among others. In addition, we explore all of these concepts from the standpoints of categories and programming in Haskell, and, in some cases, Agda. In other words, we examine functional programming through category theory.

Impressive senior project along with Haskell source code.

For the uninitiated, a conversation with functional programmers can feel like ground zero of a jargon explosion. This talk will help you to defend against the blah-blah blast by demystifying several terms commonly used by FP fans with bite-sized Haskell examples and friendly pictures. The presentation will also offer a glimpse of how some of these concepts can be applied in a simple Haskell web application. Expect appearances by Curry, Lens, and the infamous M-word, among others.

Functions are proofs. Um, I can see how that might work. Go on.

Types are propositions. Really? In what sense?

In fact, a function is the proof of the proposition its type represents. Woah, you’ve lose me now.

Don’t Panic!

The Curry-Howard Correspondence is an elegant bridge between the planet of logic and the planet of programming, and it’s not actually that hard to understand.

In this talk I’ll use the Idris dependently-typed functional programming language for examples, as its type system is sophisticated enough to construct interesting automated proofs simply by writing functions. This talk is not designed to convert you into a theoretical computer scientist, but to share with you a wonderful sight in your journey through the vast and peculiar universe of programming.

A familiarity with functional programming would be useful for appreciating this talk, but it will not require any significant prior study of theoretical computer science.

Haskell is a high-level, pure functional programming language with a strong static type system and elegant mathematical underpinnings, and is being increasingly used in industry by organizations such as Facebook, AT&T, and NASA. In the first 3/4 of the course, we will explore the joys of pure, lazy, typed functional programming in Haskell (warning: euphoric, mind-bending epiphanies may result!). The last 1/4 of the course will consist of case studies in fun and interesting applications of Haskell. Potential case study topics include automated randomized testing, software transactional memory, graphics generation, parser combinators, or others as time and interest allow. Evaluation will be based on class participation, weekly programming assignments, and an open-ended final project.

Lectures, homework, and resources on Haskell.

I particularly liked this resource and comment:

The #haskell IRC channel is a great place to get help. Strange as it may seem if you’ve spent time in other IRC channels, #haskell is always full of friendly, helpful people.

In the next couple of posts, I’m going to show how to build a parser library based on the Free Applicative Functor and what you can do with it. To follow along, clone (or update) this repo. Then ‘lein repl’ and you should be able to copy the code to see what it does.

This post runs long (again). The code is really not that long and it’s mostly very small functions. But the amount of details hidden by the abstractions takes a lot of prose to explain. Which is actually one of the very real benefits of using these abstractions. They let you implement an enormous amount of functionality in very few lines of code with fewer bugs.

If you want to see what the point of all this prose is, skip to the “Other Interpretations” section at the bottom and then come back to see how it was done.

On the other hand, if you want the full explanation, consider Applicative Programming with Effects by Conor McBride and Ross Paterson. in Journal of Functional Programming 18:1 (2008), pages 1-13.

Abstract:

In this paper, we introduce Applicative functors–an abstract characterisation of an applicative style of effectful programming, weaker than Monads and hence more widespread. Indeed, it is the ubiquity of this programming pattern that drew us to the abstraction. We retrace our steps in this paper, introducing the applicative pattern by diverse examples, then abstracting it to define the Applicative type class and introducing a bracket notation which interprets the normal application syntax in the idiom of an Applicative functor. Further, we develop the properties of applicative functors and the generic operations they support. We close by identifying the categorical structure of applicative functors and examining their relationship both with Monads and with Arrows.

The page for McBride and Patterson’s paper points to later resources as well.

Broadly speaking, functional programming is a style of programming in which the primary method of computation is the application of functions to arguments. Among other features, functional languages offer a compact notation for writing programs, powerful abstraction methods for structuring programs, and a simple mathematical basis that supports reasoning about programs.

Functional languages represent the leading edge of programming language design, and the primary setting in which new programming concepts are introduced and studied. All contemporary programming languages such as Hack/PHP, C#, Visual Basic, F#, C++, JavaScript, Python, Ruby, Java, Scala, Clojure, Groovy, Racket, … support higher-order programming via the concept of closures or lambda expressions.

This course will use Haskell as the medium for understanding the basic principles of functional programming. While the specific language isn’t all that important, Haskell is a pure functional language so it is entirely appropriate for learning the essential ingredients of programming using mathematical functions. It is also a relatively small language, and hence it should be easy for you to get up to speed with Haskell.

Once you understand the Why, What and How that underlies pure functional programming and learned to “think like a fundamentalist”, we will apply the concepts of functional programming to “code like a hacker” in mainstream programming languages, using Facebook’s novel Hack language as our main example.

This course assumes no prior knowledge of functional programming, but assumes you have at least one year of programming experience in a regular programming language such as Java, .NET, Javascript or PHP.

Or, I could have just said:

Erik Meijer is teaching this course. Enough said. 😉

Morph is a library of Haskell-style morphisms: monoids, functors, and monads. These constructs are helpful for designing programs that are purely functional and that encapsulate the boilerplate employed by many programming techniques.

Features

Implementation based on protocols and data types.

Predefined monoids and functors; with support for Clojure collections.

Library of generic functions for the above constructs.

Sample code in src/main/resources.

These constructs have a reputation of being hard to explain and even harder to understand and to apply in everyday programming. I’ve made every effort to present them as regular techniques and idioms with practical benefits. Behind their strange or fancy names, these are just functions that work on data types.

An intuition of their behavior is all that’s needed to take advantage of these functions; you may never need or want to write your own. I’m pleased with the power and simplicity these techniques have to offer and I hope you may find them useful as well.

Lowering the learning curve for using functional programming languages? Is that a bit like being able to use a compiler but not write one? Whatever drives adoption is a good thing.

When we program to interact with a turbulent world, we are to some extent at its mercy. To achieve safety, we must ensure that programs act in accordance with what is known about the state of the world, as determined dynamically. Is there any hope to enforce safety policies for dynamic interaction by static typing? This paper answers with a cautious ‘yes’.

Monads provide a type discipline for effectful programming, mapping value types to computation types. If we index our types by data approximating the ‘state of the world’, we refine our values to witnesses for some condition of the world. Ordinary monads for indexed types give a discipline for effectful programming contingent on state, modelling the whims of fortune in way that Atkey’s indexed monads for ordinary types do not (Atkey, 2009). Arrows in the corresponding Kleisli category represent computations which a reach a given postcondition from a given precondition: their types are just specifications in a Hoare logic!

By way of an elementary introduction to this approach, I present the example of a monad for interacting with a file handle which is either ‘open’ or ‘closed’, constructed from a command interface
specfied Hoare-style. An attempt to open a file results in a state which is statically unpredictable but dynamically detectable. Well typed programs behave accordingly in either case. Haskell’s dependent type system, as exposed by the Strathclyde Haskell Enhancement preprocessor, provides a suitable basis for this simple experiment.

Even without a weakness for posts/articles/books about category theory, invoking the Bard is enough to merit a pointer.

Rest easy, the author does not attempt to render any of the sonnets using category theory notation.

One of the benefits of Platform as a Service (PaaS) is that it makes it trivial to try out alternative technology stacks. The OpenShift PaaS is a polyglot platform at the heart of a thriving open-source community, the contributions of which make it easy to experiment with applications written in a host of different programming languages. This includes the purely functional Haskell language.

If you do not have an OpenShift account yet, sign up for OpenShift Online for free. You’ll receive three gears (containers) in which to run applications. At the time of writing, each of these free gears come with 512MB of RAM and 1GB of disk space.

To help you communicate with the OpenShift platform, you should install the RHC client tools on your machine. There are instructions on how to do that for a variety of operating systems at the OpenShift Dev Center. Once the RHC tools are installed, run the command rhc setup on the command line to configure RHC ready for use.

Katie’s post is a great way to get started with OpenShift!

However, it also reminds me of why I dislike Daylight Savings Time. It is getting dark later in the Eastern United States but there are still only twenty-four (24) hours in a day! An extra eight (8) hours a day and the stamina to stay awake for them would be better. 😉

Unlikely to happen so enjoy Katie’s post during the usual twenty-four (24) hour day.

The GHC Team is pleased to announce a new major release of GHC. There
have been a number of significant changes since the last major release,
including:

New type-system features

Closed type families

Role checking

An improved solver for type naturals

Better support for cross compilation

Full iOS support

Massive scalability improvements to the I/O manager

The diagrams team is very pleased to announce the 1.0 release of diagrams, a framework and embedded domain-specific language for declarative drawing in Haskell. Check out the gallery for some examples of what it can do. Diagrams can be used for a wide range of purposes, from data visualization to illustration to art, and diagrams code can be seamlessly embedded in blog posts, LaTeX documents, and Haddock documentation, making it easy to incorporate diagrams into your documents with minimal extra work.

….

Since we were talking about graphics, this seems to fit in well.

OK, one image and then you have to see Brent’s post for the rest: