prim-spoon: Catch errors thrown from pure computations using primops.

[ bsd3, error-handling, library ] [ Propose Tags ]

Takes an error-throwing expression and puts it back in the Maybe it belongs in, but with primops.

[Skip to Readme]




Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS] 0.1.0
Dependencies base (>=4.7 && <5), ghc-prim (>=, spoon (>=0.3) [details]
License BSD-3-Clause
Copyright 2016 Michael Klein, portions also licensed to: 2009 Matt Morrow & Dan Peebles, 2013 Liyang HU
Author Michael Klein
Maintainer Michael Klein <>
Category Error handling
Home page
Source repo head: git clone
Uploaded by lambdamichael at 2016-05-02T22:20:56Z
Distributions NixOS:0.1.0
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 971 total (14 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for prim-spoon-0.1.0

[back to package description]


Build Status

This is a microproject for the sole purpose of having a high-performance version of teaspoon from Control.Spoon, using primops. While it is unsafe, it is as safe as catch# and seq# from GHC.Prim. (I'd look into how safe those are, but they're hidden in GHC's source and that really seems like overkill.)

Current benchmarks suggest that primspoon takes about 3x as long as a function call on non-error throwing values and about 5x as long to catch an error and return Nothing. This is an improvment over teaspoon, which takes about 4x as long as a function call on a non-error value and about 21x to catch an error.

Why bother? Three reasons:

  1. This is my first experience with digging into primops in Haskell for performance, and it was a good exercise.
  2. I had begun to roll my own solution before I found Control.Spoon and wanted to benchmark several different solutions (for example, makeStableName).
  3. I was curious how unsafePerformIO affects performance. It turns out that it takes longer than I expected, but it makes some sense as it's not the best thing to spend time optimizing.