Projects

Lorem ipsum…

• nix

• cborg

  ⊕The design of CBOR is largely taken from MessagePack, which had been around for quite some time. The original cborg library was in fact an efficient implementation of MessagePack, authored by my colleague Duncan Coutts. But by the time it was developed in public by the both of us, it had already moved on to using RFC 7049. A fast and flexible serialization library for haskell. There are two layers to this library: the first is an interface for serializing haskell values to binary sequences that can be stored elsewhere. This is internally built on a second interface implementing RFC 7049, better known as the “Concise Binary Object Representation”. Through out most of 2016-2018, I productionized and quality-assured cborg, and used it in several production projects. Seeing a factor of 5 x speed up from swapping aeson or binary with cborg wasn’t unusual.

  While Duncan Coutts did the original implementation⊕The original design of cborg was actually based on a suggestion from Simon Meier: what if a Haskell serialization library used a “deep embedding” of syntax terms, rather than a shallow one like previous designs? This question has profound implications on the whole design, and has remained mostly unchanged for over 5 years., most of the basic package structure and basic API was refined by me. I also wrote most of the test suite and did a lot of bug-fixing and platform porting.

  Designed to be a successor to the prestigious binary library, cborg fixes several of its design deficiencies that resulted in slow code in practice, with a careful implementation that has seen significant real world use. Though, the plan to succeed binary certainly isn’t going to happen any time soon…

  While there are “faster” serialisation libraries today for raw Haskell values, I believe cborg still strikes a strong balance between speed, flexibility, and standards compliant encoding. I’m biased, of course, but if these matter to you—take a look, you might find it to be a good fit.

• glasgow haskell compiler

  The premier haskell compiler, better known as GHC. I worked on GHC for several years in my spare time, before stepping into the roll of release manager for several years as a job.⊕I was responsible for the release process behind the GHC 7.8 and GHC 7.10 releases and maintenance of the STABLE branches. The majority of this work was done for well-typed on behalf of microsoft research.

  I no longer spend time working on GHC, though I do still write much of my leisure code in haskell, of course.

• rv32-sail

  rv32-sail is an emulator for 32-bit risc-v systems. Written in sail⊕There is also a non-negligible amount of haskell involved too. as a learning experiment, it includes a mostly complete -M mode specification. You might wonder “why build another RISC-V emulator”, but why not?

  In particular, the choice of implementation in sail gives some unusually strong properties: it has good performance, strong type checking guarantees, and a simple, high-level programming model thanks to type inference, pattern matching, let bindings, and other useful features.⊕As a cool added bonus, rv32-sail can be compiled to webassembly and run directly in your browser. The instruction decoder is implemented as a high-level specification encoded in a haskell program that emits sail code.

• brisk

  Lorem ipsum…

  Brisk is a hardware design, and is implemented primarily in bluespec, with certain circuits implemented in haskell.

• libedsign

  Have you ever needed to ensure the cryptographic validity of a message with respect to a users’ public key?

  No? Well imagine you did—this library would be for you then! libedsign is a simple C library thatimplements basic cryptographic signature management APIs you can build on top of, using Ed25519 signatures. Think of it like an API you’d use to implement SSH key support. Actually, the design of libedsign was inspired mostly by the signify utility from OpenBSD, and uses a very similar encoding format, as well as some shared code.

  libedsign was originally designed while I was working at well-typed and was intended to be used as the first draft of a simple signing system for the Haskell package system, Hackage. However, after I had sketched out most of the code for libedsign, we became aware of the update framework, and based the codebase around the update framework with Ed25519 signatures instead.

  Despite all that, I believe libedsign is genuinely still useful (if niche) and mostly complete, even if it’s a bit “rusty looking” from the outside. One of these days I’ll touch it up a bit.