Edward Kmett | 7 Dec 11:19 2012
Picon

ANNNOUNCE: lens 3.7 released

Greetings!

I am happy to announce the release of version 3.7 of the lens package, which provides "Lenses, Folds, and Traversals" for working with arbitrary data types.

In its simplest form, a lens is a getter/setter pair, that can be composed and reasoned about with common sense laws that you can also derive from the Functor and Traversable laws you already know or even derive by reasoning in terms of comonad coalgebras for the even more theoretically inclined.

The lens package provides lenses along with a surprisingly powerful set of generalizations and specializations of this idea, in a manner that subsumes the notion of a "semantic editor combinator", allowing you to enrich them with the ability to read back from the targets. In the form taken by the lenses in this package, lenses are empowered to safely change the types of the fields that they edit in a manner that not only can you still reason about, but where the changes in types helps you to reason about what they can or cannot do.

One of the major design goals of lens has been that you should be able to pick up lens combinators and apply them meaningfully to a mishmash of lenses, traversals, isomorphisms, getters, and setters, etc. even without fully understanding all of the types. This encourages active exploration and users who are pleasantly surprised rather than frustrated and angry. To this end we've actively stocked the haddocks for the project with types it may be easier to think about each combinator as having, which can serve as training wheels that will help you make your way around.

Most interestingly from a package maintainer perspective, unlike previous packages that provided lenses, it is possible to provide lenses (and traversals) that are compatible with the lens library without incurring any dependency for your package at all. For instance the simplest Traversal is traverse from Data.Traversable. traverse . traverse is also a valid Traversal, and it can be composed with other lenses and traversals without any casting or coercion.

A large number of combinators are provided that automatically 'do the right thing' when presented with the various generalizations and specializations of the concept of a lens, e.g. when supplied a Traversal instead of a Lens, a combinator that returned a result based on the target of the Lens, may now return a monoidal summary of all of the results targered by the Traversal.

Major Features:

* Lenses, getters, setters, isomorphisms, folds, "prisms", monadic actions, and indexed versions of these constructions that can all be composed with (.) from the Prelude in a manner that they read quite naturally to an imperative programmer who expects (.) to be field access and to compose in the 'wrong' direction, while still retaining the ability to reason about the resulting code.

* Type-safe zippers into arbitrary user data structures, where you can move down into a lens or laterally through a traversal and can come back up, following a breadcrumb trail in the type.

* Lens contains a generalized version of Neil Mitchell's uniplate in such a way that the uniplate combinators themselves that many people already know how to use can be used on an arbitrary traversal, and uniplate/biplate simply act as a Traversal, and are often ~35% or more faster than the original.

* Lens comes "batteries included" with classes and combinators for working with many common libraries that fall within the Haskell Platform. No dependencies are incurred that fall outside of the platform, unless those dependencies are needed to implement lens itself.

* We provide configurable template-haskell generators for producing lenses, isomorphisms and traversals for your own data types.

New in this release:

* Prisms are categorically dual to Lenses and provide a form of first class pattern. They can be used directly as a Traversal. Many operations that formerly required an isomorphism can be used directly on a Prism, and every Isomorphism can be used as a Prism.

* With this latest release we've incorporated a large amount of community feedback into the API design and have vastly expanded the documentation with hundreds of additional examples and test cases.

* We've renamed a number of operations to reduce naming conflicts with third party libraries to a minimum, and improve consistency. in particular we no longer conflict with Control.Arrow. 

* We've overhauled the zipper API to permit easier use of multiple simultaneous zippers, and to make zipper movements more compositional.

Resources:

Wiki: We have a FAQ, which includes a number of links to source material, a quick getting-started guide, a discussion of the Derivation, and even a UML diagram distributed among the other content of the wiki. If you find something missing or otherwise out of whack then feel free to edit it. =)

* Larger Examples: We also have a number of larger examples included in the lens distribution, including a fully operational game of Pong that plays using Gloss and a Brainfuck interpreter.

* IRC: The #haskell-lens channel on irc.freenode.net is full of helpful people who work with or on lens itself. Lamdabot on #haskell has lens installed, and golfing solutions to user questions using lens as well as more traditional techniques has become disturbingly common.
as

* I gave a talk last month at Google in San Francisco about "Lenses, Folds, and Traversals", and just under 100 people showed up. Sadly, this talk was not recorded.

* However, I plan to give an updated version of that talk at the New York Haskell User Group meeting on Wednesday, December 12th from 7:00-9:00PM. At the time of this writing we have 94 slated as coming and room for 26 more, so if you'll be in the New York area on the 12th and are interested, register soon. =) That said, this time the talk will be recorded and the video will be made available online, so even if you can't make it out, you can still enjoy the talk.

Support: 

* We currently support the last 3 versions of the Haskell Platform, including versions of GHC back to 7.0.4 and are actively maintaining the project as part of stackage. We intend to maintain support for a rolling wave of at least 2 previous Haskell Platform releases going forward.

* If you have any questions or comments, please feel free to contact me by email, github, or IRC.

-Edward
_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Ashley Yakeley | 10 Dec 04:14 2012

Re: ANNNOUNCE: lens 3.7 released

On 07/12/12 02:19, Edward Kmett wrote:

> I am happy to announce the release of version 3.7 of the lens package,
> which provides "Lenses, Folds, and Traversals" for working with
> arbitrary data types.

Do you use types to index the fields of tuples? It's a good general 
mechanism to represent the "tupleness" of certain types. I had a quick 
look and it didn't seem you were doing this.

For instance, consider this type:

  data P = MkP Int Bool Char

If one wants to consider the three fields as separate items, one can 
construct a type that's an index to them:

  data PInd :: * -> * where
    PFirst :: PInd Int
    PSecond :: PInd Bool
    PThird :: PInd Char

It's then straightforward to construct an isomorphism between P and 
"forall a. PInd a -> a". You can also use it to build lenses for the 
fields, etc.

-- Ashley
Edward Kmett | 10 Dec 07:07 2012
Picon

Re: ANNNOUNCE: lens 3.7 released


On Sun, Dec 9, 2012 at 10:14 PM, Ashley Yakeley <ashley <at> semantic.org> wrote:
On 07/12/12 02:19, Edward Kmett wrote:

I am happy to announce the release of version 3.7 of the lens package,
which provides "Lenses, Folds, and Traversals" for working with
arbitrary data types.

Do you use types to index the fields of tuples? It's a good general mechanism to represent the "tupleness" of certain types. I had a quick look and it didn't seem you were doing this.

For instance, consider this type:

 data P = MkP Int Bool Char

 
There are classes for Field1..Field9 used for the combinators _1.._9.

If you wanted to make instances of them for your type. You could very well do

instance Field1 P P Int Int where
...
instance Field3 P P Char Char where
  _3 f (P a b c) = P a b <$> f c 

This lets you use the positional field accessors for monomorphic or polymorphic types, that may or may not allow field types to change.

If one wants to consider the three fields as separate items, one can construct a type that's an index to them:
 data PInd :: * -> * where
   PFirst :: PInd Int
   PSecond :: PInd Bool
   PThird :: PInd Char
It's then straightforward to construct an isomorphism between P and "forall a. PInd a -> a". You can also use it to build lenses for the fields, etc.

Er, I rather misinterpreted above, (I'll keep it in this reply just in case it is handy for someone else.)

We do have something rather more limited available, which is that Control.Lens.Representable let you implement corepresentable endofunctors in terms of their polymorphic lenses.

e.g.

import Control.Lens

data V2 a = V2 { __x, __y :: a }
makeLenses ''V2

instance Representable V2 where
  tabulate f = V2 (f _x) (f _y)

then you can get a number of instances for free

instance Monad V2 where
  return = pureRep
  (>>=) = bindRep

instance Applicative V2 where
  pure = pureRep
  ap = apRep

instance Functor V2 where
  fmap = fmapRep

etc...

However, the form of representation we use are lenses into the structure instead of  a GADT like index type. This currently limits us to handling functors.

This is used to good effect in the 'linear' package, which uses representable functors for all of its vector spaces. This works because, at least classically, all vector spaces are free vector spaces, and those are isomorphic to a function from a basis, so we can use a representable functor with a representation equivalent to that basis as a way to memoize the vector space.

Since it gets comparatively little use relative to the rest of the API and now that the rest of lens has matured around it, it feels somewhat different than the rest of lens, we may want to split this part off into a separate package eventually.

That said, even if we were to add the extra GADT-like index guiding tabulate, it could only do product-like constructions.

If you use IRC, the #haskell-lens channel on freenode would be a good place to dive into this deeper.

-Edward
_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Gmane