We begin with a brief problem description. We will describe the structure of a library for dealing with a data format with examples from QFPL's sv library. These libraries have parse, decode, encode, and print phases. We will discuss the benefits and drawbacks of separating or combining these phases and justify sv's strict separation. This will lead naturally to a discussion of what the library's representation of the format might look like. sv keeps a syntax tree which preserves whitespace and other information that is usually lost. This comes at a penalty in memory usage, but we will see the benefits it has in allowing us to write custom linting and sanitisation tools.

sv does not to use type classes for decoding or encoding. We will justify and motivate this choice. In particular, we can have multiple decoders of each type, including higher-order decoders like Decode a -> Decode (Maybe a). We also avoid the dreaded orphan instance problem.

Benchmarks of sv will be compared to competing CSV libraries such as cassava, and we will see that sv is slower than competing libraries. We will see what can be done about this! In particular, sv's modular design means we can integrate with fast chunks of other libraries, such as cassava's parser. This ties back to the separation of phases mentioned near the beginning, and leads naturally into the conclusion.