explicit-constraint-lens alternatives and similar packages
Based on the "Data" category.
Alternatively, view explicit-constraint-lens alternatives based on common mentions on social networks and blogs.
-
-
-
-
-
-
-
compendium-client
DISCONTINUED. Mu (μ) is a purely functional framework for building micro services. -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
text-icu
This package provides the Haskell Data.Text.ICU library, for performing complex manipulation of Unicode text. -
-
streaming
An optimized general monad transformer for streaming applications, with a simple prelude of functions -
-
CodeRabbit: AI Code Reviews for Developers
Do you think we are missing an alternative of explicit-constraint-lens or a related project?
README
This is not an introduction on how to use the library; please consult the Haddocks for that. The following assumes some familiarity with the general idea of lenses and discusses differences between this library and others.
explicit-constraint-lens is a library for generalised lenses (aka labels, functional references, accessors...)
in general called optics, i.e. it offers ways to access and/or update parts of data structures in a composable manner.
The design goals are, by order of importance:
- No restrictions. How powerful lenses can be is manifested by the
lenspackage, which offers a fine-grained hierachy from extremely strongIsomorphisms to very weak (and thus general)Folds andSetters. All these different kinds of optics are perfectly compatible, as far as this is mathematically possible, and transformations can change the type of the data structure. Here we implement that hierachy in full, which most other libraries such asfclabelsanddata-accessordo not. (Which does not mean we offer all the features oflenshere, just give a framework on which all the functionality can be implemented.) - Simple and clean interface.
lensis often criticised for being obscure, with its Var Laarhoven universally-quantified constructions such astype Iso s t a b = ∀ p f. (Profunctor p, Functor f) => p a (f b) -> p s (f t) In this library, it is merelytype Iso s t a b = ∀ c. FromIso c => Optic c s t a b - No conflict with the function data-type. Van Laarhoven lenses are just functions, albeit functions that operate in a quite surprising way and in often seemingly “in reverse direction” (via CPS). That is arguably quite elegant, but it also causes problems; in particular, the type system can not clearly distinguish between a “plain old function” and a function that's actually a lens. This is a dilemma for the future of Haskell's records, which most agree are in need of a completely new approach, to avoid the problems of name clashes and awkward special syntax. This is adressed by the Overloaded Record Fields. But many Haskellers think that lenses are the way to go and should completely replace traditional accessors, yet many others have concerns about difficulty etc..If functions and lenses can be distinguished by the type system, there is no need to decide up-front: everybody can just pick what they like better.
- Lightweight.
lensis “batteries included”, and takes quite long to build with its extensive dependecies. In its defense, the ingenuity of the Van Laarhoven signatures is that one can define ordinary lenses in a compatible manner without actually using the lens package. Themicrolenspackage therefore offers a minimal basis on which to start out. Still, it then has those signatures that are certainly not beginner-friendly, in particular when it comes to error messages, and it can not offer the full optics hierarchy – you need lots of strange category-theory classes to do that in Van Laarhoven style.
This library, by contrast, has no dependencies whatsoever and implements the full hierarchy in a single 240 LOC module, plus another 200 LOC for the most important operators and documentation.
These goals are accomplished by having
- for each flavour of optic a small dedicated type class with descriptive, consistent naming and the appropriate superclasses
- a common wrapper
OpticCthat links it all together and offers aCategoryinstance which allows our optics to be composed quite as well as the ones fromlens.
The optics are not directly compatible to Van Laarhoven signatures, but conversion is not difficult.
These ideas aren't new, really. In fact, Twan van Laarhoven suggested right in his first blog post on lenses (well before the one that introduced what would later be called “Van Laarhoven lenses”) to simply make a class
class Ref r where
ref :: (a -> b) -> (b -> a -> a) -> r a b
which does largely the same as our class FromIso c => FromLens c where lens :: (s -> a) -> (s -> b -> t) -> c s t a b Yet no prior library I'm aware of seems to have consequently taken this route.