system-f/lets-lens

Course material for lens

Let's Lens

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

http://hackage.haskell.org/package/lens

The exercises take into account various possible goals. For example, if you wish to study the history of lenses, then build up to the most recent theories, it is best to start at the Lets.GetSetLens module. If you wish to derive the structure of lenses from first principles, then derive the more modern theories, start at the Lets.Lens module.

Exercises can be recognised by filling in a function body that has a placeholder of error "todo: <function-name>".

---

Exercise modules

Lets.GetSetLens

This module presents a series of exercises, representing lenses as a traditional pair of "get and set" functions. This representation may be beneficial as it easily appeals to an intuition of "what a lens is", however, it is outdated.

These exercises are useful to gain an initial understanding of the problems that lenses solve, as well as to gain an insight into the history of lenses and how the theories have developed over time.

Lets.StoreLens

This series of exercises is similar to Lets.GetSetLens, however, using a slightly altered representation of a lens, based on the Store comonad, which fuses the typical get and set operations into a data structure. This representation is described in detail in Morris, Tony. "Asymmetric Lenses in Scala." (2012).

Lets.OpticPolyLens

This series of exercises introduces a new representation of lenses, first described by Twan van Laarhoven. This representation also introduces a generalisation of lenses to permit polymorphic update of structures.

Lets.Lens

This series of exercises starts at first principles to derive the concept of a lens, as it was first described by Twan van Laarhoven. The derivation then goes on to described other structures to solve various practical problems such as multi-update and partial update.

This representation presents a generalisation, permitting polymorphic update over structures. After lenses are derived, further concepts are introduced, such as Folds, Traversals and Prisms.

---

Credits

• Edward Kmett on the derivation of lenses

lets-lens's Issues

Rename the setter functions

In the module Lets.Lens, there is a setter function and a type alias that goes with it.

type Set s t a b =
  (a -> Identity b)
  -> s
  -> Identity t

-- | Let's write an inverse to @over@ that does the @Identity@ wrapping &
-- unwrapping.
sets ::
  ((a -> b) -> s -> t)
  -> ( a -> Identity b)
  -> s
  -> Identity t
  -- -> Set s t a b
sets f idM = Identity . f (getIdentity . idM)

mapped ::
  Functor f =>
  Set (f a) (f b) a b
mapped = sets fmap

set ::
  Set s t a b
  -> s
  -> b
  -> t
set q s b = over q (const b) s

Later in the module, we can see the use of the data structure Set, which has nothing to do with the setter functions and therefore can be confusing.
It may be worth renaming the setter functions, perhaps to update or something else.

getSuburb tests give the answer, use getSuburb

foldMapT suggests use Identity. Use Const.

Hide Prelude.product in tests

Lets.Lens: Types for `setP` and `getP` incorrect?

From here:

setP :: Prism s t a b -> s -> Either t a
getP :: Prism s t a b -> b -> t

This seems backwards.

Lets.Lens: type of `modify` incompatible with `Prism`s?

In Lets.Lens, modify has the following type signature:

modify :: Lens s t a b -> (a -> b) -> s -> t

This is fine until the final exercise, which seems to want me to use a Prism with modify:

intOrLengthEven :: IntOr [a] -> IntOr Bool
intOrLengthEven = modify intOrP (even . length)

This fails with the following type error:

src/Lets/Lens.hs:756:26: error:
    • Could not deduce (Applicative f) arising from a use of ‘intOrP’
      from the context: Functor f
        bound by a type expected by the context:
                   Lens (IntOr [a]) (IntOr Bool) [a] Bool
        at src/Lets/Lens.hs:756:19-47
      Possible fix:
        add (Applicative f) to the context of
          a type expected by the context:
            Lens (IntOr [a]) (IntOr Bool) [a] Bool
    • In the first argument of ‘modify’, namely ‘intOrP’
      In the expression: modify intOrP (even . length)
      In an equation for ‘intOrLengthEven’:
          intOrLengthEven = modify intOrP (even . length)
    |
756 | intOrLengthEven = modify intOrP (even . length)
    |                          ^^^^^^

Changing the type of modify to modify :: Set s t a b -> (a -> b) -> s -> t fixes this problem. I note that lens uses this type for over :: ASetter s t a b -> (a -> b) -> s -> t (because type ASetter s t a b = (a -> Identity b) -> s -> Identity t ).

Fold should drop the `t` and `b` parameters.

(.~) not exported