prefix-units alternatives and similar packages
Based on the "Data" category.
Alternatively, view prefix-units alternatives based on common mentions on social networks and blogs.
-
lens
Lenses, Folds, and Traversals - Join us on web.libera.chat #haskell-lens -
semantic-source
Parsing, analyzing, and comparing source code across many languages -
-
code-builder
Packages for defining APIs, running them, generating client code and documentation. -
text
Haskell library for space- and time-efficient operations over Unicode text. -
compendium-client
Mu (μ) is a purely functional framework for building micro services. -
cassava
A CSV parsing and encoding library optimized for ease of use and high performance -
unordered-containers
Efficient hashing-based container types -
-
holmes
A reference library for constraint-solving with propagators and CDCL. -
binary
Efficient, pure binary serialisation using ByteStrings in Haskell. -
-
resource-pool
A high-performance striped resource pooling implementation for Haskell -
-
primitive
This package provides various primitive memory-related operations. -
-
json-autotype
Automatic Haskell type inference from JSON input -
discrimination
Fast linear time sorting and discrimination for a large class of data types -
audiovisual
Extensible records, variants, structs, effects, tangles -
IORefCAS
A collection of different packages for CAS based data structures. -
reflection
Reifies arbitrary Haskell terms into types that can be reflected back into terms -
dependent-map
Dependently-typed finite maps (partial dependent products) -
-
-
dependent-sum
Dependent sums and supporting typeclasses for comparing and displaying them -
safecopy
An extension to Data.Serialize with built-in version control -
-
protobuf
An implementation of Google's Protocol Buffers in Haskell. -
-
orgmode-parse
Attoparsec parser combinators for parsing org-mode structured text! -
streaming
An optimized general monad transformer for streaming applications, with a simple prelude of functions -
text-icu
This package provides the Haskell Data.Text.ICU library, for performing complex manipulation of Unicode text. -
uuid-types
A Haskell library for creating, printing and parsing UUIDs -
-
scientific
Arbitrary-precision floating-point numbers represented using scientific notation -
typerep-map
⚡️Efficient implementation of Map with types as keys
Less time debugging, more time building
Do you think we are missing an alternative of prefix-units or a related project?
|
Clean code begins in your IDE with SonarLint
sponsored
www.sonarlint.org
|
Popular Comparisons
-
prefix-unitsvsaeson-qq
-
protobufvsCBOR
-
radiusvsnetwork-address
-
attemptvstext
-
binaryvsboring
|
SaaSHub - Software Alternatives and Reviews
sponsored
www.saashub.com
|
README
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
Done.
$ 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.
TODO
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.