The prefix-units package

[ Tags: bsd3, data, library ] [ Propose Tags ]

This library deals with parsing values containing "prefix units" (both binary and SI). For example, it can parse 10M and 1G, and it can also format values for displaying with the "optimal" unit. For more details, see the man page units(7), and

[Skip to Readme]


Versions 0.1.0,,, 0.2.0
Change log
Dependencies base (>=3 && <5) [details]
License BSD3
Copyright (c) 2012, 2014, 2015 Google Inc.
Author Iustin Pop <>
Maintainer Iustin Pop <>
Category Data
Home page
Bug tracker
Source repository head: git clone
this: git clone prefix-units-v0.2.0)
Uploaded Sun Nov 22 01:56:15 UTC 2015 by IustinPop
Distributions LTSHaskell:0.2.0, NixOS:0.2.0, Stackage:0.2.0, Tumbleweed:0.2.0
Downloads 1056 total (11 in the last 30 days)
Rating 0.0 (0 ratings) [clear rating]
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2015-11-22 [all 1 reports]
Hackage Matrix CI




Maintainer's Corner

For package maintainers and hackage trustees

Readme for prefix-units-0.2.0

[back to package description]

prefix-units package

This package defines a datatype (Unit) and associated parsing/formatting functions so that command line applications can handle "nice" values like:

$ cmd create-file foo 100G
$ cmd ls-file foo
Size is 100Gi
$ cmd ls-files
foo 100Gi
bar  14Ki

And so on. For details on the API, look at the Haddock documentation for the Data.Prefix.Units module.

For building and installing, cabal configure and related commands are enough. Run cabal configure --enable-tests && cabal build && cabal test if you want to run the unit-tests.

The library is designed to have very few dependencies (only base and a few GHC extensions), so that it's trivial to use it in projects. Hence the use of some hand-coded conversions instead of using TemplateHaskell to generate them automatically.


The current interface of the library works, but is not nicely composable. I'm still looking for a nicer way to expose the parsing functionality.

Currently, the binary and SI units are mixed in the same data-type. This works, but at some level I think two separate types would be more "correct", at the expense of a more complex API.

The RationalConvertible type class has only a few instances; ideally we'd have instance Integral a => RationalConvertible a and similar for Fractional, but this doesn't work as such in Haskell, so we're stuck with the manual derivation.

The current behaviour is case-sensitive for all units in ParseExact mode, which means that one has to use (in this mode) Ki for the binary unit Kibi. This seems suboptimal, since the binary units are unique irrespective of casing.