Here were the ones implementing "lens-like" functionality, loosely in order of my opinion on their usefulness for my own purposes:

• fclabels: straightforward, lenses built on underlying Point type, with support for lenses that can fail in ArrowZero
• data-lens: uses natural a -> (s -> a, s) formulation for lens, leveraging category theory abstractions from the packages created after the breakup of Edward Kmett's category-extras (a.k.a. the Big Bang)
• partial-lens: the above but suppporting failure on the container
• data-accessor: package description has nice background, implementation (not exported, oddly) is same as Data.Lens, apparently used to have wonky State monad implementation, seems from a similar school as "lenses" package
• state-record: Lens type composed of simple setter/getter function pair, with TH generator and misc. functions for use with State monad
• lenses: based on MonadState/StateT, odd formulation with no concrete type representation for the lens itself
• edit-lenses: implementation of ideas from this paper with demos here, rather... involved
• pointless-lenses: based on this paper. also rather involved, for instance here is a Lens (Tree a) [a]
• recursion-schemes: another of EK's packages. there's allegedly a lens hiding here among the zygohistomorphic prepromorphisms (you think I'm joking)

For an analysis of various approaches to lenses which don't necessarily have an implementation on hackage, these slides by Twan van Laarhoven were quite good, even without the accompanying talking human. Conal Elliot's Semantic editor combinators pattern seems also relevant to mention here.

Here's a list of the reverse dependencies for these, as a guage of popularity/general usefulness:

What about record-y packages?

As a bonus, here are the packages which attempt to augment or improve on records. I didn't spend much time trying to grok these:

• ixset: fancy indexable, groupable records gone wild
• records: records as groupable name/value pairs, perhaps similar to ixset
• has: entity-based records, looks novel but don't understand it after a quick look
• grapefruit-records: record system for grapefruit FRP, haven't looked at implementation
• fields: high-level interface and cute syntax for record operations, built on fclabels, unmaintained
• setters: just generates "setter" functions for record fields using TH

My own thoughts

The appeal of lenses for me is that they offer a first-class setter/getter on which one can build abstractions and more powerful libraries, not simply save the programmer some key strokes. Lenses that simply throw an error when applied to the wrong constructor are not suitable for this purpose.

IMHO the only package above that provides a straightforward lens type for real algebraic data types is the seemingly unused 'partial-lens' variant on Data.Lens. In which the simplified representation is:

newtype Lens a b = Lens (a -> Maybe (b -> a, b))

The 'fclabels' package is great, but handles failure on set only w/r/t both the outer value and the inner value to be set. This means we can perform validation on a data type with its setter (cool!), but means we cannot partially apply a lens and get back a pure setter b -> a which is a real problem for me.

The API has changed significantly, but should be more stable at this point. You can try it with a:

$ cabal install pez

You can find the code on github here. I will try to post some fun examples here in the next week or two.

cabal install simple-actors

This version is significantly more coherent, powerful and simple than the original 0.0.1 version (which was something I just whipped together for a blog post I haven't gotten around to writing yet).

Let me know if you have any comments or suggestions!

Que? The fclabels package is a haskell library providing "first class labels" for haskell data types and some Template Haskell code for automatically generating said labels. This makes for a more composable and much more powerful alternative to haskell's built-in record syntactic sugar. Here is a good introductory tutorial.

The new version features (besides some better names) a type for lenses that can fail. S.V. et al. added this functionality in a brilliant and mostly (except for the name changes) backwards compatible way. We'll see how it all works now.

We'll prepare a module for fclabels in the usual way:

{-# LANGUAGE TemplateHaskell, TypeOperators #-}
import Control.Category
import Data.Label
import qualified Data.Label.Maybe as M
import Prelude hiding ((.), id)

The only odd thing above is our qualified import of Data.Label.Maybe which provides getters, setters etc. that can fail.

We want to generate lenses for the following type, so we do the underdash thing:

data Example = X { _int :: Int , _char :: Char}
             | Y { _int :: Int , _example :: Example }

Notice how _int is a valid record for both constructors X and Y, where the other two are partial functions.

Lastly, the usual splice for generating labels:

$(mkLabels[''Example])

Let's load our file into GHCi and play a little:

Prelude> :l test.hs
[1 of 1] Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> get int $ X 1 'a'
1
*Main> M.get int $ X 1 'a'
Just 1
*Main> M.get char $ X 1 'a'
Just 'a'
*Main> M.get example $ X 1 'a'
Nothing
*Main> get example $ X 1 'a'
:1:5:
    No instance for (Control.Arrow.ArrowZero (->))
      arising from a use of `example'
    Possible fix:
      add an instance declaration for (Control.Arrow.ArrowZero (->))
    In the first argument of `get', namely `example'
    In the expression: get example
    In the expression: get example $ X 1 'a'

Above we saw that:

• the total int label could be used in both get and Data.Label.Maybe.get

• M.get on our "partial lenses" (example and char) safely returned a Maybe value.

• pure get used with partial lenses doesn't type check

We need to look at some types (note I've cleaned up some of these type signatures, yours may look uglier):

*Main> :t get
get :: (f :-> a) -> f -> a
*Main> :t M.get
M.get :: (f M.:~> a) -> f -> Maybe a
*Main> :info (:->)
type (:->) f a = Data.Label.Pure.PureLens f a
          -- Defined in Data.Label.Pure
*Main> :info (M.:~>)
type (M.:~>) f a = Data.Label.Maybe.MaybeLens f a
          -- Defined in Data.Label.Maybe

You can see above that setters and getters are monomorphic. But how then were we able to use int in both get and M.get? Time to look at the types of our TH-generated lenses:

*Main> :t int
int
  :: Control.Arrow.Arrow (~>) => Lens (~>) Example Int
*Main> :t char
char
  :: (Control.Arrow.ArrowZero (~>),
      Control.Arrow.ArrowChoice (~>)) =>
     Lens (~>) Example Char
*Main> :t example
example
  :: (Control.Arrow.ArrowZero (~>),
      Control.Arrow.ArrowChoice (~>)) =>
     Lens (~>) Example Example

Whoah! Lenses themselves are polymorphic in the Arrow class; partial lenses have additional restrictions of ArrowZero and ArrowChoice allowing for failure and choice.

This is wizardry of the highest order.

Notice how we can still compose lenses freely, whether partial or total:

*Main> :t (.) (.) :: Category cat => cat b c -> cat a b -> cat a c 
*Main> M.get (int . example) (Y 1 (X 2 'a')) Just 2

A note on mkLabelsNoTypes

I had been using the noTypes variation to generate lenses that I was exporting in a module, because the TH-assigned type sigs looked pretty nasty. If you do this with >1.0 you will run into the monomorphism restriction and ambiguous type variables.

Instead I would suggest defining exported lables by hand and giving them a nicer looking (or monomorphic if you prefer) type sig.

You can even let fclabels generate the code and just paste it in, e.g.:

Prelude> :set -ddump-splices
Prelude> :l test.hs
[1 of 1] Compiling Main             ( test.hs, interpreted )
test.hs:1:1: Splicing declarations
    mkLabels ['Example]
  ======>
    test.hs:40:3-21
    char ::
      forall ~>[a1kk]. (Control.Arrow.ArrowChoice ~>[a1kk],
                        Control.Arrow.ArrowZero ~>[a1kk]) =>
      Lens ~>[a1kk] Example Char
    {-# INLINE[0] CONLIKE char #-}
    char
      = let
          c[a1kl]
            = (Control.Arrow.zeroArrow Control.Arrow.||| Control.Arrow.returnA)
        in
          Data.Label.Abstract.lens
            (c[a1kl]
           . Control.Arrow.arr
               (\ p[a1km]
                  -> case p[a1km] of {
                       X {} -> Right (_char p[a1km])
                       _ -> Left GHC.Unit.() }))
            (c[a1kl]
           . Control.Arrow.arr
               (\ (v[a1kn], p[a1ko])
                  -> case p[a1ko] of {
                       X {} -> Right (p[a1ko] {_char = v[a1kn]})
                       _ -> Left GHC.Unit.() }))

chan-split is a haskell library that is a wrapper around Control.Concurrent.Chans that separates a Chan into a readable side and a writable side.

We also provide two other modules: Data.Cofunctor (because there didn't seem to be one anywhere), and Control.Concurrent.Chan.Class. The latter creates two classes: ReadableChan and WritableChan, making the fundamental chan functions polymorphic, and defining an instance for standard Chan as well as MVar (an MVar is a singleton bounded channel, wanna fight about it?).

Why?

Having separate read/write sides makes it easier to reason about your code, supports doing some cool things (defining Functor and Cofunctor instances), and makes more sense (e.g. the function of dupChan in the base library is much easier to understand as an operation that happens on an OutChan).

Also I use it in (the coming new, less stupid version of) my module simple-actors.

Where?

You can get it with a:

cabal install chan-split

And check out the docs on hackage. Or check out the source on github and send me pull requests.

Usage

Let's write the numbers 1 - 10 to the InChan and read them as a stream in the OutChan:

module Main
    where

import Control.Concurrent.Chan.Split
import Control.Concurrent(forkIO)

main = do
    -- Instead of a single Chan, we initialize a pair of (InChan,OutChan)
    (inC,outC) <- newSplitChan
    -- fork a writer on the InChan
    forkIO $ writeStuffTo inC [1..10]
    -- read from the OutChan in the main thread:
    getStuffOutOf outC >>=
        mapM_ print . take 10

And we'll make writeStuffTo and getStuffOutOf, simply be the standard functions. Note that writeListToChan is actually polymorphic.

writeStuffTo :: InChan Int -> [Int] -> IO ()
writeStuffTo = writeList2Chan

getStuffOutOf :: OutChan Int -> IO [Int]
getStuffOutOf = getChanContents

Now I'll demonstrate the use of our Functor and Cofunctor instances by re- defining those two functions above, after importing our Cofunctor class

import Data.Cofunctor

...

-- we could convert the [Int] to [String] here but will instead demonstrate the
-- Cofmap instance:
writeStuffTo :: InChan String -> [Int] -> IO ()
writeStuffTo = writeList2Chan . cofmap show

-- likewise this demonstrates the Functor instance of OutChan:
getStuffOutOf :: OutChan String -> IO [Int]
getStuffOutOf = getChanContents . fmap read

All right, leave your love or hate and stay tuned for the new (less stupider) simple-actors lib.