The prefix-units package

[Tags:bsd3, library, test]

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 CHANGES
Dependencies base (>=3 && <5) [details]
License BSD3
Copyright (c) 2012 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.1.0)
Uploaded Fri May 4 01:07:24 UTC 2012 by IustinPop
Distributions LTSHaskell:0.2.0, NixOS:0.2.0, Stackage:0.2.0, Tumbleweed:0.2.0
Downloads 964 total (5 in the last 30 days)
0 []
Status Docs uploaded by user
Build status unknown [no reports yet]




Maintainer's Corner

For package maintainers and hackage trustees

Readme for prefix-units

Readme for prefix-units-0.1.0

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 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.