cscalfani

Fun with Function Application (Elm version)

Function application operators in Elm make programming more understandable and help reduce parenthesis.

(<|)

The application operator, <|, can be used to reduce the need for parenthesis. The following:

cscalfani

Fun with Function Application (Haskell version)

Function application operators in Haskell make programming more understandable and help reduce parenthesis.

($)

The application operator, $, can be used to reduce the need for parenthesis. The following:

cscalfani

How to think about Monads

UPDATE 2021: I wrote this long before I wrote my book Functional Programming Made Easier: A Step-by-step Guide. For a much more in depth discussion on Monads see Chapter 18.

Initially, Monads are the biggest, scariest thing about Functional Programming and especially Haskell. I've used monads for quite some time now, but I didn't have a very good model for what they really are. I read Philip Wadler's paper Monads for functional programming and I still didnt quite see the pattern.

It wasn't until I read the blog post You Could Have Invented Monads! (And Maybe You Already Have.) that I started to see things more clearly.

This is a distillation of those works and most likely an oversimplification in an attempt to make things easier to understand. Nuance can come later. What we need when first le

cscalfani

You're thinking about map all wrong

I was watching Phil Freeman's "Fun with Profunctors" talk on YouTube and about an hour into it he shows an example from the lens library:

λ> import Control.Lens
λ> view (_1 . _2) ((10, True), 42)
True
λ> 

cscalfani

(Compose) Compose (Compose)

Motivation

Multiple times I've wanted to understand how to derive the following by hand:

(.) . (.) :: (c -> d) -> (a -> b -> c) -> a -> b -> d

Which is the point free version of:

cscalfani

Discovering Applicative Functors in Haskell

When first learning Applicatives, they always seemed an oddball thing to me. At first, Functors made sense and Monads sort of made sense, but Applicatives felt shoehorned in between the two.

That is until I was reading Programming In Haskell by Graham Hutton, Second Edition (section 12.2) on Applicatives. His explanation takes a bit of a leap and is presented in an odd order, but I think I can reorder the information in such a way that we can feel as if we are discovering Applicative Functors (or Applicatives for short) ourselves.

Start with Functor

Let's remind ourselves of the Functor class definition:

cscalfani

Monads of Functions in Haskell

We're all pretty familiar with Monads that contain values, e.g. Maybe a and Either e a. Typically, these are value type, e.g. Maybe String, Maybe Int, Either String Int, Either MyError MyResult.

When fmap is called on a Maybe Int, it is clear that the Int is going to be mapped to its new value when the fmap is evaluated, e.g.:

fmap (* 10) Just 1 === Just 10

cscalfani

Functional Composition with Multiple Parameters in Haskell

In the past, I've written composition functions in both Elm and Haskell that take multiple parameters for the leftmost function, i.e. the function that gets applied first.

(All examples here are in Haskell)

Here was my Haskell implemenation (stolen from the web):

compose2 :: (c -> d) -> (a -> b -> c) -> a -> b -> d

cscalfani

Monoids in Haskell, an Introduction

Why should programmers care about Monoids? Because Monoids are a common pattern that shows up over and over in programming. And when patterns show up, we can abstract them and leverage work we've done in the past. This allows us to quickly develop solutions on top of proven, stable code.

Add Commutative Property to a Monoid (Commutative Monoid) and you have something that can be executed in parallel. With the end of Moore's Law, parallelism is our only hope to increasing processing speeds.

What follows is what I've learned after studying Monoids. It is hardly complete, but hopefully will prove to be helpful as an introduction for others.

Monoid Lineage

cscalfani

Covariant and Contravariant Functors

This article contains more than enough examples to hopefully understand Covariant and Contravariant Functors and how to create them for many situtations.

Note that all type annotations use Int as the concrete type but any concrete type would be equivalent as would any mix of concrete types.

It assumes a general understanding of Functor and a basic understanding of Haskell type classes and data types.

Mapping from a to b(#1)