typed-encoding alternatives and similar packages
Based on the "typed" category.
Alternatively, view typed-encoding alternatives based on common mentions on social networks and blogs.
Do you think we are missing an alternative of typed-encoding or a related project?
Type level annotations, string transformations, and other goodies that make programming strings safer.
I have recently spent a lot of time troubleshooting various
UTF-8 encoding issues.
I decided to write a library that will help avoiding issues like these.
This library allows to specify and work with types like
-- some data encoded in base 64 mydata :: Enc '["enc-B64"] c ByteString -- some text (utf8) data encoded in base 64 myData :: Enc '["enc-B64", "r-UTF8"] c ByteString
It allows to define precise string content annotations like:
ipaddr :: Enc '["r-IpV4"] c Text
and provides ways for
- recreation (encoding validation)
- type conversions
- converting types to encoded strings
- typesafe conversion of encoded strings to types
... but this approach seems to be a bit more...
-- upper cased text encoded as base64 example :: Enc '["enc-B64", "do-UPPER"] () T.Text example = encodeAll . toEncoding () $ "some text goes here"
It becomes a type directed, declarative approach to string transformations.
Transformations can be
- used with parameters
- applied or undone partially (if encoding is reversible)
One of more interesting uses of this library are encoding restrictions.
(Arbitrary) bounded alpha-numeric (
and a simple annotation Boolean algebra are both provided.
phone :: Enc '["r-ban:999-999-9999"] () T.Text phone = ... -- simple boolean algebra: phone' :: Enc '["boolOr:(r-ban:999-999-9999)(r-ban:(999) 999-9999)"] () T.Text phone' = ...
Goals and limitations
The main goal is to provide improved type safety for programs that use string encodings and transformations. Not to provide encoding implementation type safety. Encoding and string manipulation libraries are typically well established and tested, type safety is really needed at the usage site, not at the implementation site.
This library approach is to fight issues with (value level) strings using (type level) strings. Using
Symbol-s effectively forces us to play the orphan instances game.
One of the long term goals is for this library to provide combinator alternatives to typeclass polymorphism so that the orphan instances are more of a convenience and not the necessity.
Here are some code examples:
- [Conversions between encodings](src/Examples/TypedEncoding/Conversions.hs)
- [Adding a new encoding, error handling](src/Examples/TypedEncoding/Instances/DiySignEncoding.hs)
- [To and from string conversions](src/Examples/TypedEncoding/ToEncString.hs)
- [Unsafe - working inside encodings](src/Examples/TypedEncoding/Unsafe.hs)
Other encoding packages
My approach will be to write specific encodings (e.g. HTTP) or wrap encodings from other packages using separate "bridge" projects.
Currently /typed-encoding/ depends on
- /base64-bytestring/ because it was my driving example, this is likely to move out to a separate bridge project at some point.
- v0.3 has numerous changes and improvements.
- stack (1.9.3) lts-14.27 (ghc-8.6.5)
- needs ghc >= 8.2.2, base >=4.10 for GHC.TypeLits support
- running test suite: cabal has problems with doctest, use stack