Spoke Proof

Hao Lian's They Might Be Giants Fan Page Constructed with the Care and Attention of a Circa-Early 2000s Geocities Page

Sun, 04 Jun 2017 00:00:00 +0000

Perpetually under construction so don’t even get me started.

Vying for first place in the competition among Spoke Proof blog posts to be the most self-indulgent claptrap ever assembled into HTML.

What is TMBG?

They Might Be Giants is a force of rock and roll that has been around since the late 1980s. Their music is eclectic and then some. They sound like the music that would play over the PA in your dream of circus. Their catalog is huge. Unsubstantiated opinion, given with the energy of a drunk bar patron who’s trying to pick a fight: You should listen to them in chronological order.

Favorite Lyrics

My armchair theory is that a person’s soul can be triangulated by their three most favorite They Might Be Giants lyrics. With their range and their corpus of words you should be able to express any interesting truth about the universe.

That being said, these lyrics are listed in an arbitrary order.

Someday mother will die and I’ll get the money

There’s a restaurant we should check out where the other nightmare people like to go I mean nice people, baby wait, I didn’t mean to say nightmare

No one in the world ever gets what they want and that is beautiful

Then came a knock on the door which was odd / And the picture abruptly changed

Soon the man who sweeps the room brings the secret telegram / COMMENCE OFFICIAL INTERPLANETARY EXPLORATION

And I think about the dirt that I’ll be wearing for a shirt / And I hope I get old before I die (live!)

Favorite Facts About TMBG

John Linnell used to be a bike messenger and he would bike around NYC all day singing songs he made up to himself

The number one rule of the TMBG fan club is to unequivocally deny that you are a member if ever asked and to instead pretend that you have no knowledge of the existence of any fan club

One day TMBG will stop producing new music and there will be nobody else left to catch whatever odd bursts of inspiration from the cosmic depths that TMBG is alone able to intercept

Ancillary Material You Should Check Out If You’re a Fan

TMBG in sixty minutes (Jesse Hassenger)

Neil Casey episode on Don’t Get Me Started (Will Hines, Anthony King)

The Grand March 2017 Links Roundup

Mon, 13 Mar 2017 00:00:00 +0000

streaming is a Haskell package with a manifesto. The author presents a strong argument for modeling streaming as a compiler-friendly version of FreeT, the free-monad transformer.

Somewhat of a golden age of profunctors is happening among Haskell weblogs. We have “Profunctors, Arrows, & Static Analysis”, “Monoids on Steroids”, and “Addressing Pieces of State with Profunctors”.

Kmett’s answer on “Today, I used laziness for…” reaches some sort of ecstatic plane for /r/haskell commenting and leads the reader down a rabbit hole of “close the circle”-type lazy programming. See also: “Water collected between towers” and the solution with Control.Monad.Tardis. h/t doug

“An algebra of graphs” is now an ICFP paper!

“A case of reflection” is a tutorial on introducing runtime information through compiletime superclass constraints with the all-star reflection package.

Exploring the Curry-Howard correspondence in Dhall.

Join points have landed in GHC 8, leading to impressive gains in allocation benchmarks. For more information, see SPJ’s talk on demystifying GHC Core at around minute 50 or read “Compiling without continuations”.

“Derivable Type Classes” is an old Hinze and SPJ paper that proposes a what-if for generic programming that never came to be:

class Eq a where
  (==) :: a -> a -> Bool
  
  (==){1} Unit Unit = True
  (==){a + b} (Inl x) (Inl y) = x == y
  (==){a + b} (Inr x) (Inr y) = x == y
  (==){a + b} _ = False
  (==){a * b} (x :*: y) (z :*: w) = x == z && y == w

sheyll/type-spec is an insane type-level test framework.

Validating Aeson with nst/JSONTestSuite

Wed, 26 Oct 2016 00:00:00 +0000

While we sit with bated breath, waiting for the latest Apple laptop and clearing out space in our storage containers for USB-C converters, I recommend reading Nicolas Seriot’s Parsing JSON is a Minefield; the article exhaustively mines the JSON specification for ambiguities and presents a suite of tests to run against several well-known JSON parsers. It punctures the myth that JSON is well-specified by any means of the imagination. Chalk it up to yet another example (Mark Pilgrim’s classic blog post on RSS specifications) of taking shortcuts in specifications and then having to pay it back tenfold.

Anyway I ran the test suite on Aeson 0.11.2.1. Aeson, if you’re not familiar, is the de facto JSON library for Haskellers. It serves to highlight many of the great qualities of modern functional programming. For one, Aeson is an example of what you can build with attoparsec, an incredibly efficient library of bytestring-parsing combinators: a safe, well-typed, extremely fast sea-worthy library. I find using Aeson to be a joy.

Aeson scores mostly positively, which does not make for a great blog post but does make for good news for those of us who have deployed Aeson to production. There are however a few minor unpleasant things to point out from the test suite’s results.

Floating-point numbers, our close friend

One obvious takeaway is that Aeson liberally accepts floating-point numbers, even when they might be invalid by the specification – see the chunk of results starting with n_number_-2..json. These numbers are accepted by Aeson without question:

-01
-2.
0.e1
2.e+3
2.e-3
2.e3
-012
1.
012

These numbers are all invalid JSON, believe it or not. For decoding, this seems fine to me. Encoding is the one I worry about: I can see Aeson generating these strings and then another parser crashing or failing on the resulting input. That could lead to some particularly nasty 3 AM page to your weary ops team. Fortunately, it does seem particularly rare that you would generate these sorts of numbers on purpose – I imagine very few number formatters would choose to output something as horrendous as these examples. This is more damning of the specification than anything: why the JSON specification insists on not versioning itself, and why the JSON specification insists on its own version of representing floating point numbers, is beyond me.

Perhaps the recommendation here should be this: do not try to represent real numbers in JSON this way. Resort instead to using a rational number (in JSON it could be a tuple of the numerator and the denominator), at least for anything serious.

Unicode, our close friend

The other, more worrying, takeaway is that Aeson rejects these two otherwise-valid inputs:

FFFE[00"00E900"00]00

This is ["é"], encoded as UTF-16. Aeson fails with the message Failed reading: not a valid json value.
["\uFFFF"]

Aeson fails with the message Failed reading: Cannot decode byte '\\x8f': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream.

(The underlines are a clever syntax I am borrowing from the original blog post but are a little hard to explain. Each set of two underlined characters indicates the hexadecimal representation of a byte. While I could have pasted the raw UTF-16 bytes into the source code of this blog post, most of the characters would have been invisible. For example, FFFE is the byte-ordering mark but it has no visible representation. Instead what Nicholas did is write out the hex. Think of it as a partial hexdump – normal characters are preserved, but anything extraordinary is converted into this underlined hexadecimal format. This is different from the backslash escape, which indicates literal text for the JSON parser to unescape – no byte trickery here.)

These are both valid inputs (the first one being a test of UTF-16 decoding, and the second one being a pretty simple case), and these errors seem to be bugs in the Aeson parser code. However! It looks like a recent pull request, four days old as of writing, addresses the second point. The first point might be moot – does Aeson even guarantee UTF-16/UTF-32 decoding? Those two encodings do seem baroque in 2016, and it is unclear if implementing support for them is worth the tradeoff for performance. Aeson is popular, after all, due to its impressive performance optimizations.

Stray observations

By the way, some of Nicholas’s tests came out of the American Fuzzy Lop fuzzer, which traces the assembly instructions taken by a binary on a given input in order to reduce and mutate said input. An elegant, simple idea. We can thus point to this article as yet another successful usage of AFL, the software project most likely to achieve sentience and take over the world one day.
What a shame that Mark Pilgrim’s weblog no longer exists. It was such a tentpole of technical writing back in the early days when people blogged on individual websites and we could stitch together new posts with RSS feeds. People took the time to put little touches on their websites; before MovableType came along a lot of people built their own commenting systems, which usually had fun little features and personality quirks. Everybody laid out their archives a little differently. You could tell which website was whose from a glance. Weblogging used to be harder, but it also used to be more a labor of love.

Functors in Haskell, co- contra- and pro-

Tue, 30 Aug 2016 00:00:00 +0000

Warning

The following blog post, which started out as an unruly unkempt footnote, was hastily written to be a link to reference whenever I finish this other (even longer) blog post on profunctors and lenses. If you are not familiar with negative/positive signing for type variables I point you toward this wonderful article on co/contravariance in Haskell, which probably explains this all better than I could.

Functors

So I was told a functor in Haskell is any type with kind * -> * that admits an instance for the class

class Functor f where
  fmap :: (a -> b) -> (f a -> f b)

And I am here to tell you that this is a lie. Or, well, not a lie but at least a slightly myopic way of thinking about things.

I like to think about functors like this: any type parametrized on a where a only appears in non-negative positions usually is a functor on the type a. This sounds like nonsense, but take as an example this type:

newtype FromInt = FromInt (Int -> a)

This type easily admits a Functor instance: given an a -> b, we simply compose it onto our Int -> a to get an Int -> b. A more complicated example:

data [a] = [] | a:[a]

It turns out that a never appears in a negative position here, but it is hard to see because we have obfuscated the actual type with Haskell’s lovely ADT syntax. We can convert this to its equivalent type:

newtype List a = List (forall r. r -> (a -> List a -> r) -> r)

To implement the Functor instance: given an a -> b, we destructure the list. In the nil case we have no work to do; in the cons case we apply our function and recurse:

instance Functor List where
  fmap a2b (List alist) =
    List (\nil cons -> alist nil (\a as -> cons (a2b a) (fmap a2b as)))

Take a moment to convince yourself that this works precisely because a never appears in the negative position. We can illustrate this point better by looking at a type where this rule is violated:

Contravariant functors

newtype Predicate a = Predicate (a -> Bool)

Given an a -> b … there is not much we can do. There is no way to get a b -> Bool out. What would be really nice however is if we had a b -> a, because then we could just compose the two functions and get a Predicate b. As a matter of fact, this little nugget of intuition holds true for type over a where a never appears in a positive position. To give this idea life we create a Functor-like class but with the arrow going the other way. We call it Contravariant:

class Contravariant f where
  contramap :: (a -> b) -> (f b -> f a)

instance Contravariant Predicate where
  contramap a2b (Predicate b2bool) = Predicate (b2bool . a2b)

We can call this new type of functor a “contravariant” functor and realize that the functor we were talking all along above was a “covariant” functor. Just names to distinguish between the never-positive/never-negative rules, although theoretically speaking we are sort of deriving our vocabulary backwards.

Another example:

newtype Const constant a = Const constant

instance Contravariant Const where
  contramap _ (Const c) = Const c

instance Functor Const where
  fmap _ (Const c) = Const c

Because a appears in neither a positive nor negative position (nonvariant/invariant) we were able to demonstrate Const r to be both a covariant and contravariant functor.

Armed with this knowledge, this type from the lens package takes on a charged meaning:

type Getter s a = forall f. (Contravariant f, Functor f) => (a -> f a) -> s -> f s

What can we say about the a or the s in f a/f s? What types could f be? What type will f usually be?

Profunctors

What about types parametrized over both covariant variable and contravariant variables? They could admit both a Functor and a Contravariant (if we allow the order of their variables to be reordered in the declaration) but it would be much more useful to do both at the same time. And for that we have

class Profunctor p where
  dimap :: (contra' -> contra) -> (co -> co') -> p contra co -> p contra' co'

The typeclass of * -> * -> * types where the first star never appears in a negative position and the second star never appears in a positive position. Examples include:

-- a negative
-- b positive
newtype (->) a b = a -> b

instance Profunctor (->) where
  dimap s2a b2t a2b =
    b2t . a2b . s2a

-- a negative
-- b positive (if m is a covariant functor)
newtype Kleisli m a b = Kleisli (a -> m b)

instance Monad m => Profunctor (Kleisli m) where
  dimap s2a b2t (Kleisli a2mb) =
    Kleisli (fmap b2t . a2mb . s2a)

I believe it is difficult for newcomers to this idea to see profunctors as anything except obfuscation, especially when the only two instances ever presented are the (->) or the Kleisli ones. I am highly sympathetic to this point of view. Profunctors as a tool for the Haskell programmer require a little extra juice to motivate, and it comes in the form of our old friend parametricity. Parametricity is a tool to make arguments about what kinds of values can inhabit a given tyupe.

For example: the type forall a. a -> a can only admit one non-trivial value: id. It is impossible to write a function more specific than id because the forall a. constraint gives us very little to work with. Another way is to cast this into mathematical logic: by assuming the fewest possible premises, we must only derive the most general theorem. As such, forall a. a -> a is an excellent way to represent the identity function.

By a similar argument, type Mirror s a = forall p. Profunctor p => p a a -> p s s is an excellent way to represent an isomorphism between the type s and t. For example, an isomorphism between Data.Text.Text and String might look like this:

packed :: Profunctor p => p Text Text -> p String String
packed = dimap pack unpack

We can then use this to go forwards (recovering pack)…

λ> newtype Forget r a b = Forget { unForget :: a -> r }
λ> instance Profunctor (Forget r) where
     -- Here we are "forgetting" the b2b' value, which
     -- would be `unpack` in our example above. Assuming
     -- a2r = id (which it is in our example below), this
     -- neatly grabs the `pack` function and throws away
     -- the rest.
     dimap a'2a b2b' (Forget a2r) = Forget (a2r . a'2a)
λ> :t unForget $ packed (Forget id)
unForget $ packed (Forget id) :: String -> Text

… and backwards (recovering unpack).

λ> newtype Reverse p s t a b = Reverse { unReverse :: p b a -> p t s }
λ> instance Profunctor p => Profunctor (Reverse p s t) where
     -- Here we are reversing the order of the functions
     -- passed to `dimap`. Assuming mirror = id (which
     -- is in our example below), this is the simple
     -- switcheroo we need to obtain the reverse iso.
     dimap a'2a b2b' (Reverse mirror) = Reverse (mirror . dimap b2b' a'2a)
λ> :t unReverse $ packed (Reverse id)
unReverse $ packed (Reverse id) :: Profunctor p => p String String -> p Text Text
λ> let unpacked = unReverse $ packed (Reverse id)
λ> :t unForget $ unpacked (Forget id)
unForget $ unpacked (Forget id) :: Text -> String

As laid out in Phil Freeman’s excellent “Fun with Profunctors” talk, this type – by virtue of parametricity over the Profunctor p – can only represent an isomorphism. Because this type is so general (again, assuming the fewest premises to derive the most general theorems) we can only act upon it in a couple of ways:

We can compose isomorphisms together. The arrow -> in the middle of the type allows us to use our old friend (.); note that this requires no knowledge of p and thus can be done without having to specify one.
We can choose a profunctor p, construct a p s s, apply it to the type, and recover a p t t. With Forget above, we unwrap to retreive a weakened forward version of the isomorphism. With Reverse, we unwrap to retrieve the flipped isomorphism, as if we meant to construct it backwards all along (dimap unpack pack instead of dimap pack unpack). This might be surprising! It would seem as if dimap pack unpack would “lose information” about the functions we passed, but here we see evidence that dimap in fact preserves just enough information to allow us to retrieve both the functions we pass in.

Far be it for me to talk about parametricity as some sort expert; for that I refer you to Bartosz’s wonderful blog post Money for Nothing and Theorems for Free.

This representation of isomorphisms is especially potent. By introducing additional constraints on top of Profunctor p, we can represent lenses and prisms – type Lens s a = forall p. (Profunctor p, Strong p) => p a a -> p s s, type Prism s a = forall p. (Profunctor p, Choice p) => p a a -> p s s. For a full presentation of this idea, watch Phil’s talk! For me profunctors were a complete mystery until I saw functional, composable optics derived this way. Another benefit of watching the talk? The design of the lens package makes sense. I used to view lens as a UML diagram of impossible ideas and strange nouns. Now? Now I have a newfound appreciation for the work Haskellers have done in making higher-kinded types, rank-n polymorphism, and typeclasses available in a production-quality language. These are tools by which we build powerful, user-friendly, eminently-composable libraries and tools. So ends this overstuffed footnote.

Haddock at your fingertips

Tue, 30 Aug 2016 00:00:00 +0000

Dash for macOS (and by the way welcome to the universe where we type macOS with a straight face) made documentation cool by way of docsets, which are collections of indexed offline HTML files with table-of-contents and RSS-feed push publishing. Simple technologies strung together by glue and displayed in a pretty, keyboard-friendly app.

Thesis: for Haskell users, docset viewers like Dash are more or less mandatory. Most Haskell packages are a buffet of tiny functions ordered into deep hierarchies of modules. If we could get Dash and Haddock to be friends we could then

Fuzzily search by function or module names;
Click on Source links to look at function source, often just as illuminating as the documentation;
Confidently write Haskell in the Brooklyn Botanical Garden, which is next to our apartment but lacks an internet connection.

This is well within our reach thanks to philopon/haddocset, a Haskell library and executable that eats package database configuration files and uses the information to mutate a docset.

Here are the steps:

Set up a working Haskell environment with Stack.
stack upgrade; stack new scratch; cd scratch; stack install haddocset (we will want a scratch project to work in; as you will see you do not want the dependencies you will be building to overlap with your global project)
Modify the dependencies section in scratch.cabal to list the packages you want to have included in your docset. I have an example further down on this page.
alias -g .fast='--fast --ghc-options="-j +RTS -A1024m -n2m -RTS"'
stack build --haddock --stack-root $(pwd)/.root/ .fast (we have to build in a new Stack root because Stack will helpfully skip over packages that have already been registered into your official root, even though they probably lack Haddocks)
Make coffee. Putter around the household. Read. Check out /r/overwatch for the latest plays of the game. Wonder which character you will play next. Compulsively check the Slack channel you set up with your friends to see if anybody else is playing. When you close your eyes to sleep at night you see the Mercy’s ultimate indicator on your screen. “Heroes never die!” rings in your head at work. Should you go professional? You wonder how you will do when competitive play is released. Check your savings account to figure out how long you could be unemployed while you train to go professional. Consider moving to the suburbs in Somerville, Massachusetts to make your savings last longer.
Use zsh for its globbing syntax.
alias h="stack exec haddocset -- "
DOCSET=/tmp/scratch.docset
h -t $DOCSET create
ls -1 ~/.stack/snapshots/**/pkgdb/*.conf > confs
ls -1 .stack-work/**/pkgdb/*.conf >> confs
gsort -V confs (use GNU sort(1) to version-sort the lines so that e.g. foo/lts-6.12/bar/ comes after foo/lts-6.3/bar/)
stack list-dependencies | while read -r name version; do echo "$name-$version"; done | xargs -I{} zsh -c 'grep {} confs | tail -1' > deps
h -t $DOCSET add $(cat deps) -f
open $DOCSET # opens the docset in Dash on OS X

What the fuck are you doing

These pkgdb .conf files live in your .stack-work/ and .root/ directories. Unfortunately there are multiple .conf files, one for each version of a package that you have used on your machine. We want to grab all these confs and then do a mathematical set intersection with the list of transitive dependencies generated from our scratch.cabal (see below). By transitively including all our dependencies we will ensure that inter-package links in the Haddock will work.

Furthermore: when we intersect we want the latest version of each package, which is why we gsort -V and run xargs grep tail.

We already have a finished turkey in the oven

In the end you should end up with a docset like mine, generated on June 16th 2016 with the scratch.cabal below, aggressively zipped into a 33 MB download.

[snip]
library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       HTTP
                     , aeson
                     , array
                     , base >= 4.7 && < 5
                     , base-prelude
                     , bifunctors
                     , conduit
                     , esqueleto
                     , http-api-data
                     , lens
                     , lens-aeson
                     , mtl
                     , path-io
                     , persistent
                     , plan-b
                     , servant-client
                     , servant-server
                     , servant-swagger
                     , swagger2
                     , transformers
                     , uri-bytestring
                     , wreq
                     , zip
                     , vector
[snip]

You should of course modify the build-depends block for the packages you use frequently. You can probably tell from mine that I am one of those heathen artless web programmers who deceive companies into paying me a market salary for the simple task of converting JSON over HTTP to SQL queries and back. By the way the NYC Originate office is hiring Haskell developers.

Release notes

2016 June: Original post; nothing to write home about
2016 August: Typos fixed; --stack-root discovered and written about; gsort -V hack to work around lts-6.XX version numbers

The always-updated treasure map to Haskell

Fri, 19 Aug 2016 00:00:00 +0000

Many people coming into Haskell are daunted by number of choices they have to make: which package to use, which package manager to use, which language extensions to turn on, which resources to read.

So here are some sensible default choices. I’ve noted wherever the answer is still up in the air. Most things are! Many problems in our world have good, but not great, solutions.

Setting up a Haskell environment on OS X

Use stack. Stack

Is a sandbox-style package manager. For each project it creates a hermetic little world filled with the project’s dependencies and the project itself.
Sets up a “global” project, which is the default project you work in when you run stack outside a project.
By the way, a project is any directory with a *.cabal or a package.yaml file or any subdirectory thereof. I highly recommend using package.yaml files, otherwise known as the hpack format. With *.cabal files you have to type the name of each module separately and you have to maintain per-target dependencies. What a hassle.

Also installs GHC (stack setup) for you.
Also maintains your PATH. If you run stack exec foo or stack ghci, you’re running foo and ghci in the context of your project’s sandbox.

Awooga: OS X users will be tempted to use Homebrew to install Stack but that will compile it from source, which takes a good hour on a desktop and possibly longer on laptops. (I have never been patient enough to find out.) Best to just unzip an official release.

The community

Is the best part of Haskell. The community is incredibly kind and supportive. /r/haskell is a medium-traffic subreddit filled with library announcements, fascinating discussions, questions answered by experts, and much else besides. Try Stack Overflow too.

Learning Haskell

Learn You a Haskell for Great Good!
Try Haskell! An interactive tutorial in your browser
What I Wish I Knew When Learning Haskell by Stephen Diehl
Write You a Haskell by Stephen Diehl
The original paper by Philip Wadler that proposed the Monad typeclass – surprisingly readable
Cryptopals – not the worst way to learn Haskell, and you’ll learn modern applied information security to boot (You will probably need Crypto.Cipher.AES128 or Crypto.Cipher.AES.Haskell to complete the first chapter.)
Chris Allen’s “How to learn Haskell”, another collection of links. Has perhaps the best advice written about Haskell: Don’t sweat the stuff you don’t understand immediately. Keep moving!

Creating a new package

$ cd ~/workspace
$ stack new hello

The pain of compilation

Compiling Haskell is slow. Add this to your global aliases (assuming you use zsh):

alias .fast='--fast --ghc-options="-j +RTS -A1024m -n2m -RTS"'

It will teach GHC to use (1) all your cores and (2) more memory while compiling.

Another useful global alias (assuming you use zsh):

alias .fw='--file-watch'

Usage:

stack build .fast .fw
stack ghci .fast
stack install lens .fast

Another suggestion: rebind ; to : in your terminal preferences. When Haskelling I never type semicolon but I sure do type colon all the time.

Editor environment

You can’t go wrong with my Haskell Emacs scratchpad. Emacs and Vim are both pretty good choices. Really you need these things:

Syntax highlighting
Live parsing and typechecking
hlint’s suggestions
Autocompletion of horribly long module names
Being able to send code to an interactive GHC REPL
Restarting the REPL when your .cabal file changes
Being able to go from
```
  f x = x
```
to
```
  f :: a -> a
  f x = x
```
with one keypress.

With the right packages, Emacs and Vim have all these features.

IDEs: hdevtools or Intero

This is an active field of development!

hdevtools runs a GHCi process in the background and lets your editor interactively query it for typechecking and code-reloading purposes. Comes with integrations for Emacs, Vim, Atom, and Sublime. This is the one that I use.
Intero is an Emacs-specific IDE and a rising star. I have not used this much but people speak highly of it.

HTTP client

Use wreq.

HTTP server

Use warp. It implements WAI. If you’re coming from Python, WAI is Haskell’s WSGI. Or Ruby’s Rack. Or Perl’s PSGI.

WAI even supports HTTP/2 now.

HTTP framework

This is an active field of development!

This is more divisive. I like to think of each web framework by what new technologies and abstractions they use. These three have all picked very interesting choices, making the Haskell web framework field very diverse:

Snap: Snap uses lenses in a neat way that lets you attach additional information to the request at each middleware layer. I think I’m drastically oversimplying snaplets.
Yesod: Yesod has great documentation. It also uses conduits, which is a neat little library for modeling streams (with – and this is the hard part – reasonable memory management and error handling) in Haskell. It uses Template Haskell to remove some of the boilerplate of web programming.
Servant: Servant is newer but has a cool higher-kinded routes system where you can declare the type of your entire API with type-level programming.

This isn’t like Python or Ruby’s web framework ecosystem, where everybody has sort of decided to coalesce around a monolithic, invent-the-wheels framework (Django, Rails) with lots of smaller, more modular options (Camping, Sinatra, Flask). Lens, conduits, and type-level programming are all cutting-edge stuff.

Web Sockets

Use jaspervdj/websockets for insecure port-80 Web Sockets; use Taylor Fausak’s wuss to get TLS.

JSON

Use Aeson.

Unicode text

Use Data.Text. It’s built on bytestrings and is fast and supports the bare minimum Unicode slicing and dicing. For more Unicode support, see text-icu.

Binary data

Use Data.ByteString. If you need to represent text, upgrade yourself immediately to text.

Lazy text or bytestrings?

I would say avoid them unless you really know what you’re doing. I say this as somebody who doesn’t know what he’s doing.

Lazy IO?

Lazy IO causes more heartache with resource management and error handling than you would expect. Try pipes or conduit instead, which lets you build out streaming data pipelines without leaking file handles or badly handling IO errors. Unfortunately they’re both a little hard to use.

OpenGL

This is an active field of development!

The most comprehensive and well-organized OpenGL library for Haskell is gl by Edward Kmett. How it works is elegant: it downloads the OpenGL specification into a gl.xml file and then it produces a Haskell library from that XML file. Code that writes code. Its documentation is poor, however; for a tutorial see the primer on Wright Access. For toy examples, see ekmett/quine. Unfortunately the graphics story for Haskell is not quite all there yet.

Lenses

You’re going to keep hearing about lenses because the lens package has achieved remarkable success in the past couple of years, both in terms of creativity and popularity. This series of blog posts takes the time to explain and derive lenses. Lenses tutorials have the same problem as monad tutorials. The reason lenses and monads exist is long-time Haskellers all noticed the same problem, and a lot of (abstract) thought went into thinking of a solution. The original sin of lenses is functionally updating a complicated data structure. The solution is … complicated.

Some lens tips and tricks:

Prisms, getters, setters, traversals, and uppercase-L Lens in the lens package all compose with . It all typechecks and type-inferences. This seems simple but it isn’t. It is one of those inventions, like Isaac Newton’s catflap, that does the magic of rendering the blindingly simple into existence. And that’s the secret genius of the lens package: against all odds, they got all the optics to compose with with .. (Aside: It is impossible in most other languages as it takes advantage of two unique Haskell features, rank-_n_ polymorphism and typeclasses.)
If you compose a bunch of lens together, you get back the lowest common denominator on this UML diagram. So composing a setter with anything automatically makes it the result a setter. And you can’t compose a setter with a getter – you need a Lens. And a Lens composed with a traversal is always a traversal. And only compositions of isomorphisms will yield an isomoprhism. Against all odds, they got all this UML diagram to work exactly as you think it would.
99% of lens usage boils down to bigDataStructure operator (lens1 . lens2 . lens3), where operator is one of ^., ^?, or ^...
Stop packing and unpacking your strings into bytestrings and vice versa. Use Data.Text.Lens and Data.ByteString.Lens.
Stop calling toStrict/fromStrict and toChunks/fromChunks to convert between strict and lazy bytestrings (and texts). Use Control.Lens.Iso instead.

Prelude

The default prelude is super annoying because you keep importing tiny minimodules like Data.Monoid and Data.Maybe to get their helpers. The base-prelude package does all this for you, but you have to turn off implicit preludes (-XNoImplicitPrelude).

Pointfree

blunt is a little web app that gives you the pointfree version of any function. Be prepared to encounter headache-inducing oddities like (.) . (.) or the Applicative instance for (->) r.

Searching by types

If Hoogle can’t find it, try Hayoo.

Short functions

A good thing to watch out for is functions in Haskell that last for longer than five lines. These might take the form of long do blocks, or a mess of let ... in ... s and wheres. These often signal that the function is doing too much. Whereas in other languages we might resign ourselves to the mess, in Haskell we can do better.

I find writing a clean function f involves asking myself:

Is f is the composition of some series of functions? f = foo . bar . baz is one kind of function composition. But so is f = foo >>= bar >>= baz (and its categorical cousin f = foo >=> bar >=> baz).
Is f a map over some structure? If I’m taking a list and producing a list, I usually reach for map and filter.
If f folding a big structure into a smaller structure, which aggregates or summarizes the information in the big structure? If I’m taking a list and producing a single value, I usually reach for foldr and filter.

Horizon

Upcoming GHC developments we should be excited about:

Great Haskell blogs

Well-Typed
Haskell for all by Gabriel Gonzalez
Bartosz Milewski’s Programming Cafe
Neighborhood of Infinity by Dan Piponi
Inside 736-131 by Edward Z. Yang
Simon Peyton Jones – don’t be put off by the academic paper format, as spj is a highly capable technical writer
Edward Kmett’s talks on YouTube

Parametricity a.k.a. theorems for free

Using types and typeclasses to generate and prove theorems about a function’s invariants. This is like if all your life you carried around this intuition about how something works and then one day someone came along and validated all of it with mathematics and good writing.

@parametricity
Parametricity: Money for Nothing by Bartosz Milewski
Parametricity Tutorial (Part 1) by Edsko de Vries
Theorems for free! by Philip Wadler

Opting into strictness

Confused about seq and weak-head normal form? Read Roman Cheplyaka’s blog post on forcing lists.

Fiber

The older you get, the more you’ll appreciate a moderate amount of fiber in your daily diet.

Monospace font

Try Ubuntu Mono!

Updates to this document

2015 Nov 30: the initial draft was published after a rousing discussion in my friends and I’s #haskell Slack channel.
2016 Jan 3: added Web Sockets mention after a fun day with Slack’s real-time messaging API.
2016 Aug 18: hdevtools and intero mentioned. Typos fixed.

What your HTTP development port says about you

Fri, 17 Jun 2016 00:00:00 +0000

8000: you own more than two ties
8001: someone offered you pot once and exactly once
8002: you spend more money on domains each year than you do on clothes
8069: you still think about her
8080: you used to wear sneakers that lit up when you walked
8765: you have casual Friday marked down in your calendar
8888: most of your food is microwaved
9000: you lost your virginity to someone older than you
80: you don’t give a fuck
1: you have a tattoo of the OSI networking model