You can play with it or check out the code on GitHub; in particular, see “algorithm.js” for the didactic implementation of the algorithm.

It uses jQuery and Raphael.js for the visuals and events.

Goals for the project

1. create a fun visual simulation that can give a nice intuition for the algorithm

2. remain true to the algorithm as described in the paper, and to avoid anything novel or clever at this point

3. attempt to organize my code in such a way as to be a readable explanation of the algorithm as described in the paper, hiding or isolating implementation details

4. attempt to model the behavior of a real-world network of nodes using the OO abstraction, and (synchronous) events.

Trying to meet these demands was revealing. For one thing I was forced to break up the two message exchange steps into four discrete steps which must be performed synchronously across the network for things to work without race conditions.

Later

The pseudocode description is hiding some of the complexity and brittleness of the algorithm IMHO. I’d like to take it apart and try to rip out as many of the synchronous-network dependencies as I can, or explore how an identical but asynchronous system behaves: give all the nodes jittery clocks and without a coordinated start.

After a bit of research and tweaking, the following worked well enough for me:

Run it in your browser’s JS console on the page you want to process (we assume jQuery is already loaded on the page).

cabal install yall

or check it out on github. There will be a Template Haskell library for automatically deriving lenses at some point in the future.

I was motivated primarily by the desire for a lens that is acceptable for pez (existing libs such as the excellent fclabels or data-lens didn’t fit the bill for assorted reasons), and to explore some abstractions and generalizations re lenses more deeply.

The result is fairly rough at this point, but I’m interested in feedback.

Distinguishing features

This is a bit of copy/paste from the docs I just wrote.

• Lenses are parameterized over two Monads (by convention m and w), and look like a -> m (b -> w a, b). this lets us define lenses for sum types, that perform validation, that do IO (e.g. persist data to disk), etc., etc.

• a module Data.Yall.Iso that complements Lens powerfully

• a rich set of category-level class instances (for now from categories) for Lens and Iso. These along with the pre-defined primitive lenses and combinators give an interface comparable to Arrow

Examples

And here is a little showcase of functionality. First, an illustration of partial lenses, appropriate for multi-constructor types.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

-- First, lenses for a sum type. This is something like what we'll generate
-- with template haskell.
data Test a = C1 { _testString :: String, _testA :: a }
            | C2 { _testString :: String, _testRec :: Test a }

-- pure lens, polymorphic in Monad for composability:
testString :: (Monad w, Monad m)=> Lens w m (Test a) String
testString = Lens $ \t-> return (\s-> return t{ _testString = s }, _testString t)

-- lenses that can fail. For now, use Maybe. In the TH library, I'll probably
-- generate lenses polymorphic in <http://hackage.haskell.org/package/failure>
testA :: LensM Maybe (Test a) a
testA = Lens f where
    f (C1 s a) = return (return . C1 s, a)
    f _ = Nothing

testRec :: LensM Maybe (Test a) (Test a)
testRec = Lens f where
    f (C2 s i) = return (return . C2 s, i)
    f _        = Nothing

-- conposing a pure and partial lens:
demo0 :: Maybe String
demo0 = getM (testString . testRec . testRec) (C2 "top" (C1 "lens will fail" True))

Now an example of a more creative use of monadic getter, allowing us to define a lens on the “Nth” element in a list, returning our results in the [] monad environment.

1
2
3
4
5
6
7
8
9
10

-- Here we have a lens with a getter in the list monad, defining a mutable view
-- on the Nth element of the list:
nth :: LensM [] [a] a
nth = Lens $ foldr nthGS []
    where nthGS n l = (return . (: map snd l), n) : map (prepend n) l
          prepend = first . fmap . liftM . (:)

-- This composes nicely. Set the Nth element of our list to 0:
demo1 :: [ [(Char,Int)] ]
demo1 = setM (sndL . nth) 0 [('a',1),('b',2),('c',3)]

Finally here’s a bit of a silly example illustrating a lens with Monadic setter (w) that does IO, in this case persisting a serialized version of the data we’re operating on to a text file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

-- persist modifications to a type to a given file. An effect-ful identity lens.
persistL :: (Monad m) => FilePath -> Lens IO m String String
persistL nm = Lens $ \s-> return (\s'-> writeFile nm s' >> return s', s)

-- we'll use this one:
tmpFile = "/tmp/yall-test"
printFileContents = putStrLn . ("file contents: " ++) =<< readFile tmpFile

-- build a lens with some pre-defined Iso's that offers a [Int] view on a
-- string that looks like, e.g. "1 2 3 4 5":
unserializedL :: (Monad w, Monad m) => Lens w m String [Int]
unserializedL = isoL $ ifmap (inverseI showI) . wordsI

-- now add "persistence" effects to the above lens so everytime we do a "set"
-- we update the file "yall-test" to redlect the new type.
unserializedLP :: (Monad m) => Lens IO m String [Int]
unserializedLP = unserializedL . persistL tmpFile

demo2 :: IO ()
demo2 = do
    -- apply the lens setter to `mempty` for some Monoid ([Char] in this case)
    str <- setEmptyW unserializedLP [1..5]

    -- LOGGING: the string we got above (by setting [Int]) was written to a file:
    print str
    printFileContents

    str' <- modifyW unserializedLP (map (*2) . (6 :) . reverse) str

    -- LOGGING: now the file was modified to reflect the changed value:
    print str'
    printFileContents

Future

I still need to create TH deriving functionality for the package, and will announce when that happens. Been busy lately so I’m not sure when I’ll get to it, but let me know your questions/comments/concerns and I’ll try to address them promptly.

Here is how it’s defined:

1
2
3
4
5
6

-- lexicographical ordering
instance Monoid Ordering where
        mempty         = EQ
        LT `mappend` _ = LT
        EQ `mappend` y = y
        GT `mappend` _ = GT

Without the comment I don’t know if I would have gotten it right away, but check this out:

Prelude> :m + Data.Monoid 
Prelude Data.Monoid> zipWith compare "asff" "asdf"
[EQ,EQ,GT,EQ]
Prelude Data.Monoid> let compare' s = mconcat . zipWith compare s
Prelude Data.Monoid> compare' "asff" "asdf"
GT

A string comparison function can be defined using the comparisons of corresponding letters (, numbers, etc.) as Monoids.

It’s easy to see how mappend defined above works, when you think of it applied as a left fold on [EQ,EQ,GT,EQ]. But here is the really cool result: it follows from the definition of a Monoid…

mappend x (mappend y z) = mappend (mappend x y) z

that the reduction can take place in any order:

Prelude Data.Monoid> EQ `mappend` EQ `mappend` GT `mappend` EQ
GT
Prelude Data.Monoid> EQ `mappend` (EQ `mappend` GT) `mappend` EQ
GT
Prelude Data.Monoid> EQ `mappend` ((EQ `mappend` GT) `mappend` EQ)
GT
Prelude Data.Monoid> (EQ `mappend` (EQ `mappend` GT)) `mappend` EQ
GT
Prelude Data.Monoid> ((EQ `mappend` EQ) `mappend` GT) `mappend` EQ

That surprised me!

The wikipedia page for Lexicographical order has some awesome information, and nice illustrations that give a good intuition about this stuff.

I wanted to develop an approach iteratively so I’d learn something along the way, but I didn’t take great pains to document the process very well, nor do I have any analysis here of low level details.

The best version is a github gist here if you want to play with it and optimize further.

Playing with the algorithm

First here’s a very naive declarative approach. This describes the nature of the problem beautifully, but is slow as hell since we don’t try to re-use computations:

medNaive :: String -> String -> Int
medNaive [] s2 = length s2
medNaive s1 [] = length s1
medNaive s1@(c1:cs1) s2@(c2:cs2) = minimum 
    [ medNaive cs1 s2 + 1
    , medNaive s1 cs2 + 1
    , medNaive cs1 cs2 + if c1==c2 then 0 else 2
    ]

And here’s a version that is pretty much the standard matrix algorithm. Because we’re using a boxed array we can actually query the array while we build it:

import Data.Array

-- boxed array are what allow for this:
med :: String -> String -> Int
med s1 s2 = 
    let bnd = (length s1, length s2)
        prep = zip [0..] . ('\NUL' :)

        -- a list comprehension might fuse here where do notation doesn't
        a = array ((0,0),bnd) $ do
            (n1,c1) <- prep s1
            (n2,c2) <- prep s2
            let minEd 
                  | n1==0 = n2
                  | n2==0 = n1
                  -- compare w/ min + min:
                  | otherwise = minimum
                      -- insert:
                      [ (a!(n1-1,n2)) + 1
                      -- delete:
                      , (a!(n1,n2-1)) + 1
                      -- substitute:
                      , (a!(n1-1,n2-1)) + if c1==c2 then 0 else 2
                      ]
            return ((n1,n2), minEd)

     in a ! bnd

Initially, I’ll be benchmarking with criterion on two random 200-character strings. The test main function looks like:

main = defaultMain [
            bench "simple array version" $ whnf (uncurry med) (string1, string2)
            [

For this initial array version, compiled with -O2 we get:

collecting 100 samples, 1 iterations each, in estimated 6.440210 s
mean: 68.72456 ms, lb 68.40039 ms, ub 69.60141 ms, ci 0.950
std dev: 2.539885 ms, lb 1.197168 ms, ub 5.383915 ms, ci 0.950

But we don’t need to keep around the entire matrix, especially if we only want the final edit distance value, so iterating over the first string for each character of the second string should be a more efficient approach.

Here’s a version just using lists. This is the logical flavor of the algorithm we’ll be using going forward:

medList :: String -> String -> Int
medList s1 = finalCost . foldl' scanS1 (zip [1..] s1, 0) -- 0 is cost comparing nul -> nul
          -- "fills in" what would be a column of our matrix
    where scanS1 (v, costSW_i) c2 = 
              let (_, v') = mapAccumL scanVec (costSW_i, costSW_i + 1) v
                  -- given accumulator corresponding to costs to the southwest
                  -- and south, and the current character and cost from the
                  -- previous step (cost to the west) find min sub-edit:
                  scanVec (costSW, costS) (costW, c1) = 
                     let cost = min (min costS costW + 1)
                                    (costSW + if c1 == c2 then 0 else 2)
                      in ((costW, cost), (cost, c1))
               in (v' , costSW_i + 1)
          finalCost = fst . last . fst

This runs a bit slower than the array version above, but is a good starting point for further enhancement:

collecting 100 samples, 1 iterations each, in estimated 9.095287 s
mean: 103.2585 ms, lb 102.7181 ms, ub 103.8645 ms, ci 0.950
std dev: 2.926384 ms, lb 2.473240 ms, ub 3.647964 ms, ci 0.950

Vectors

Let’s see if we can translate the algorithm we developed with lists to use the Vector type from the vectors package, to see how much benefit we can get from the highly-optimized stream-fusable operations in that package.

Here we’ve just replaced one of the lists since there’s no drop-in replacement for the mapAccumL we’re using:

medVec :: String -> String -> Int
medVec s1 = finalCost . V.ifoldl' scanS1 (zip [1..] s1) . V.fromList
    where scanS1 v costSW_i c2 = 
              -- TODO: see if we can turn this into a fold, scanl, or zipWith?
              --       or perhaps accum from Vector?
              let (_, v') = mapAccumL scanVec (costSW_i, costSW_i + 1) v
                  scanVec (costSW, costS) (costW, c1) = 
                     let cost = min (min costS costW + 1)
                                    (costSW + if c1 == c2 then 0 else 2)
                      in ((costW, cost), (cost, c1))
               in v'
          finalCost = fst . last

This runs about as fast as medList above. We need more Vector juice.

With a little thought we can turn the mapAccumL above into a scan and iterate our scan over a Vector for S1 as well. Using the strict postscanl' function here also yielded a huge speed-up from the non-strict version.

medVecFinal :: String -> String -> Int
medVecFinal s1 = V.last . V.ifoldl' scanS1 costs_i . V.fromList
    where vs1 = V.fromList s1
          costs_i =  V.enumFromN 1 $ V.length vs1 -- [0.. length s1]
          scanS1 costs_W costSW_i c2 = 
              let v =  V.zip vs1 costs_W
                  v' =  V.postscanl' scanVec (costSW_i, costSW_i + 1) v
                  scanVec (costSW, costS) (c1, costW) = 
                     (costW, min (min costS costW + 1)
                                 (costSW + if c1 == c2 then 0 else 2))
               in snd $ V.unzip v'

This is about twice as fast. Sweet!

collecting 100 samples, 2 iterations each, in estimated 9.639692 s
mean: 49.64144 ms, lb 49.33944 ms, ub 49.94830 ms, ci 0.950
std dev: 1.561553 ms, lb 1.359085 ms, ub 1.955104 ms, ci 0.950

Notice that the code above does no indexing or destructive updates; it’s written entirely as though we were working on lists.

Unboxed Vectors

By just changing my vector import line to import qualified Data.Vector.Unboxed.Safe as V I got a huge speed-up on the last implementation above (15x in fact… spooky stuff).

collecting 100 samples, 19 iterations each, in estimated 6.332280 s
mean: 3.379753 ms, lb 3.371200 ms, ub 3.391660 ms, ci 0.950
std dev: 51.03072 us, lb 39.59751 us, ub 76.56945 us, ci 0.950

And it appears to run in constant space which is a good thing.

The LLVM backend didn’t seem to improve the benchmarks.

Summary and TODOs

So our final vector version is about 30x faster than the original list version we used as a prototype, and it still just looks like list-processing code and we haven’t needed to muck around with strictness hints, or INLINE pragma (not that there aren’t improvements to be had there).

I would like to play with a further optimization to the algorithm that drops non-ascending prefixes from the cost vector we iterate over, but ran out of time. If I mess with that, I’ll probably explore the effects of destructive updates at the same time.

Improvements will end up on the gist I linked to above. Feel free to fork and improve!

Anyway the result is my library named shapely-data which you can get with the usual…

cabal install shapely-data

and is up on github here.

The library can be used to convert an algebraic data type into a form that replaces its constructors with a combination of (,), Either and (). See the haddocks for usage information, and implementation details.

This first 0.0 version is very raw. Please let me know if you might find this useful or have any ideas/feature-requests. If there is any interest I will polish this thing sooner rather than later.

Motivation

I wanted to demonstrate that Either and (,) are haskell’s primitive sum and product types, and to show that we can more or less represent any regular type using these in combination with the unit type (standing in for the empty constructor a.la Nothing).

So the type

data Foo a = FooPair a a
           | FooInt Int
           | FooEmpty

can be converted into

newtype ShapelyFoo a = ShapelyFoo { 
    shapelyFoo :: Either (a,a) (Either Int ())
}

The deeper motivation is that there are a lot of neat abstractions (mostly having some relation to category theory) that require some notion of sums and products, and I don’t see any better way of representing this notion in the type system. It seems most straightforward to design abstractions around (,) and Either.

Arrow gets criticized for (among other things) its explicit use of these types, but a class parameterized over the sum or product type (as in A. Megacz’ “generalized arrows”) becomes complicated and the abstraction breaks down with no suitable way to talk about products and sums in general AFAICT.

So this gets at the problem from the other direction: we reduce arbitrary types to haskell’s primitive sum and product types, allowing code to be written against these types, and then “flattening” the primitive representation back onto a normal type of the same shape. I’m imagining list processing using the ArrowChoice interface on Either (a, List a) () for instance.

Ultimately maybe this can get us some of the goodness of Structural Typing for certain applications. It’s also a somewhat lighter-weight approach to generic programming, and might be useful for:

• generic view functions and lenses
• conversions between similarly-structured data, or “canonical representations” of types
• incremental Category-level modification of data structures, e.g. with Arrow
• serializing data types

…but again, I’m not an expert and this is just scratching a personal itch of mine.

TODOs

Here’s a quick list of things on my mind of things to do and questions to be answered for potential future releases:

• lots of misc. polishing like handling record types, derived instances, etc.
• handle constructor-less (bottom) types: data Foo
• handle recursive types in some intelligent way, so that we can do conversions between e.g. a custom List a and [a]
• figure out how to think about ordering of sum types: how can we make Either Int () equivalent to Either () Int during conversions? Should we?
• what about “deep” conversions that also look at a constructor’s arguments?

med. format prints here always taken with a yashica 635 TLR and printed at safelight, in Studio Two Three.

Consider something as simple as:

newtype Bij a b = Bij (a -> b) (b -> a)

a Category instance is trivial, but an Arrow instance is impossible, since we would need to supply a b -> a given only a a -> b.

And yet most of the Arrow methods (except arr and &&&) would be useful for, and can be implemented in a very reasonable way, for the type above:

(Bij bc cb) *** (Bij xy yx) = Bij (bc *** xy) (cb *** yx)
first b                     = b *** id
second b                    = id *** b

We omit &&& above because there isn’t a reasonable way to define a general function :: (c -> b) -> (c' -> b) -> ((c,c') -> b

(Bij bc cb) &&& (Bij bc' c'b) = Bij (bc &&& bc') undefined

…without something like a “restricted Arrow” where b is constrained to Monoid. (but I’m getting ahead of myself; more on why I don’t think &&& belongs in Arrow anyway below).

Or as a reductio ad absurdum, consider simply the following type:

newtype Flipped a b = Flipped (b -> a)

is there any reason we shouldn’t have an Arrow-like class for which the above can be an instance?

None of this is new; it is a common complaint about Arrow: that it is overly complex (to the point of feeling arbitrary), while being extremely limited.

Won’t someone think of the Lenses?

Anyone who has tried to write a lens library has wished they could use the Arrow abstraction and slammed their head into a wall for at least an hour before giving up (except probably Edward Kmett). They just really ought to be Arrows.

Consider this lens representation:

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

&&& will give us the same problems as the (admittedly very similar) Bij example above, but the other methods (***),first and second have good implementations that would even preserve the Lens Laws (they are what you would expect, but also have some foundations in CT)

An ArrowChoice implementation should also be no problem to implement while also being practically useful for lenses.

Again though, arr presents a problem. One might even try to implement it as a getter combined with a const/”read-only” setter continuation like:

arr f = Lens $ \a-> (const a, f a)

But this violates the first Arrow law arr id = id.

What is the nature of the problem?

From the above, it is obvious that we have problems with types where the flow of the computation is reversed from the order of the type variables. We can also probably find types that are sort of composite categories with a natural Category instance but no way to lift a pure computation.

But here’s another slightly different type of example; a computation with an associated cost, perhaps defining the “energy required” for a certain transformation:

data Transformation a b = T Int (a -> b)

instance Category Transformation where
    id = T 0 id
    (T n f) . (T n' g) = T (n+n') (f . g)

Again, this type lends itself well to the parallel composition operators in Arrow. For instance &&& can capture that composing two transformations into a single one that “fans out” carries the cost of the sum of their energy requirements:

(T n f) &&& (T n' g) = T (n+n') (f  g)

But the only logical implementation for arr that we can define, arr f = T 0 f, breaks the law arr (f >>> g) = arr f >>> arr g.

I started to do a survey of types on hackage that are Category but not Arrow, but got burnt out at the stage where I had to actually look through the code. Still this would be a great thing to do.

Default implementations without arr

If we rip arr out of the Arrow class, we lose a lot of the default methods, which are implemented in terms of some primitive “identity-like” functions lifted to Arrow with arr. Here are those functions from the main class:

-- second in terms of first, and vice versa:
\(x,y) -> (y,x)
-- &&& in terms of ***:
\b -> (b,b)

and these are the helpers from ArrowChoice:

-- right in terms of left:
either Right Left
-- ||| in terms of +++:
either id id

It’s useful to try to think of implementing these primitive helpers in a given Category, e.g. for some Category c can we implement swap :: c (x,y) (y,x)? And for any Category where we can define swap does it follow that we should always be able to define the corresponding ArrowChoice helper swapE :: c (Either a b) (Either b a)? If so, then they should be in the same new sub-class of Category, etc., etc.

I think these primitive helpers would probably be a good basis for the methods in a new class or set of classes to act as an Arrow alternative.

what about all those laws?

Most of the invariants that should hold for an Arrow are defined in terms of arr, but I think there are probably reasonable replacements, especially since there was never anything particularly rigorous about the original Arrow laws.

For example, here are some relationships which I think should be expected to hold:

• first id = second id = id
• f *** g = first f >>> second g (straight from default implementation)

but I’m not very good at this.

I suspect arr is either the anchor that allows for a well-defined Arrow class, or that all the laws are necessary to deal with the inclusion of arr. I hope the latter, and that a revised set of laws for Arrow-without-arr would look simpler and more abstract, like Monoid.

About &&&

While an arrow that can “fan out” is useful, this doesn’t belong in this class for a number of reasons:

1. It doesn’t depend on Category at all and doesn’t even require a type of kind * -> * -> *; since any Arrow can be made an Applicative anyway, this could be re-written as (&&&) :: Applicative a=> a c -> a c' -> a (c,c')

2. it appears only once in the entire implementation (in the Arrow class declaration). The Arrow laws don’t require it, nor do any of the default class implementations use it.

3. because there are many Arrow-like things which have no suitable implementation for such a function (a bit of circular logic, I know)

Concluding remarks

Arrow fails as a generally-useful and coherent class for composing Categories vertically or “in parallel”, which is I think what people are looking for.

Maybe I can come up with some code soon for a better Arrow. Such a set of classes would hopefully be simpler, more flexible, and take advantage of the Arrow = Category + Applicative correspondence.

Also as I was finishing this I just stumbled on Causal Commutative Arrows (PDF) which look interesting.

Let me know your thoughts.

Update 2/13

Thanks for all the feedback everyone. From the comments I was pointed to Adam Megacz’s work on “generalized arrows”, and there are also a few comments on the haskell subreddit.

[Overlapping types] can sometimes be simulated with the extra-method trick used in the Show class of the Prelude for showing lists of characters differently than lists of other things.

I’d never thought about how haskell-98 can support a show "asdf" that returns

"\"asdf\""

while show [1,2,3,4] returns

"[1,2,3,4]"

And I was surprised at the complexity of Show when I looked at the docs and implementation (to be honest, I had no idea how the class was implemented or that show was not the only method).

I thought the “extra-method trick” to avoid overlapping types was sufficiently cool and difficult to understand at first to warrant a short post about it. So here goes!

The basic problem

Remember that

type String = [Char]

so we can’t create an instance declaration for it in haskell-98. Something like

instance Show [Char] where
    ...

would require both FlexibleInstances and would also cause overlapping instances when we declare

instance Show a=> [a] where
    ...

since a [Char] is also a Show a=> [a]. This will never do!

The solution

To get around this, the Creators added a showList method, which allows an instance to define how a list of values of its type should be displayed. Here is the Show class:

-- note: showS is just String -> String, a CPS optimization for building up strings
class Show a where
    showsPrec :: Int -> a -> ShowS
    show :: a -> String
    showList :: [a] -> ShowS

Here’s the instance declaration for [a] where I’ve added the default show implementation from the class declaration:

instance Show a => Show [a]  where
    showsPrec _     = showList 
    show x          = shows x ""    -- default  

after a bit of indirection, we see show str is implemented as:

showList str "" 

where showList is from the Show instance for Char.

The “extra-method” trick pattern

So the general pattern here is when you have a perhaps-limited number of possibly-overlapping, recursive instances

instance Foo (Maybe Int) where
instance Foo (Maybe Bool) where

you can instead create an instance for the outer constructor:

instance Foo a=> Foo (Maybe a) where

define a new method (say maybeToFoo :: Maybe a -> Foo). And then delegate the behavior of Maybe Int and Maybe Char to the Int and Char instances respectively.

instance Foo Int where
instance Foo Bool where

Hopefully that makes sense.

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.

EDIT: I’ve just released version 0.1.0 of this library. It is a complete re-write / re-think that I think makes the library much more attractive, simple and powerful. There won’t be any more dramatic API changes.

I was in need of a simple, tight library implementing the Actor Model of concurrency and didn’t find one on hackage, so I wrote my own. You can check out the docs here and get it with a

$ cabal install simple-actors

The library is really just a thin layer around Chans, and I made no great effort to ensure that the library conforms to any particular formal definition of the actor model, but rather tried to make an idiomatic haskell library for more structured concurrent programming.

I’ve been going all sorts of ways with this and would appreciate any feedback anyone would like to share.

I’ll be using it in some (hopefully fun and interesting) posts in the near future, to model concurrent systems, and also exploring creating a more involved concurrency library. So stay tuned if that’s what you’re into.