# LGtk/ADT lenses

### From HaskellWiki

(fill subsection) |
(add interpretation) |
||

Line 146: | Line 146: | ||

* <hask>xLens</hask> remembers the value of <hask>y</hask> if we change between the constructor tags. This is the intended behaviour. |
* <hask>xLens</hask> remembers the value of <hask>y</hask> if we change between the constructor tags. This is the intended behaviour. |
||

* <hask>xLens</hask> remembers the values of <hask>v</hask> and <hask>z</hask> fields if we change between the constructor tags. This is the intended behaviour. |
* <hask>xLens</hask> remembers the values of <hask>v</hask> and <hask>z</hask> fields if we change between the constructor tags. This is the intended behaviour. |
||

+ | |||

+ | ==== Interpreation ==== |
||

+ | |||

+ | The intended behaviour can be justified if we interpret lenses as abstract editors. If we would like to define an editor of an <hask>X</hask> value, the state of the editor would be <hask>(XTag, (Int, (a, Char)))</hask>, and one could retrive the actual <hask>X</hask> value by <hask>xLens</hask> from the state. The editor would be the composition of the following simpler editors: |
||

+ | |||

+ | * An elementary editor for <hask>XTag</hask> (maybe a combo box or a checkbox) which would be connected to the editor state by <hask>fstLens</hask>. |
||

+ | * An elementary editor for an <hask>Int</hask> (maybe a text box or a slider) which would be connected to the editor state by <hask>fstLens . sndLens</hask>. |
||

+ | * An editor for an <hask>a</hask> typed value which would be connected to the editor state by <hask>fstLens . sndLens . sndLens</hask>. |
||

+ | * An editor for a <hask>Char</hask> (maybe a combo box or a text box or a virtual keyboard) which would be connected to the editor state by <hask>fstLens . sndLens . sndLens . sndLens</hask>. |
||

+ | |||

+ | Now, the intended behaviour is the following: |
||

+ | |||

+ | * If the user fills in an <hask>Int</hask> value for <hask>y</hask>, this value should remain the same after changing the <hask>XTag</hask> value. |
||

+ | * The <hask>a</hask> value editor should be active only if the <hask>XTag</hask> value is <hask>X1Tag</hask>. |
||

+ | * The <hask>Char</hask> editor should be active only if the <hask>XTag</hask> value is <hask>X2Tag</hask>. |
||

+ | * If the user fills in an <hask>a</hask> value for <hask>z</hask> when the <hask>XTag</hask> value is <hask>X1Tag</hask>, and the user changes <hask>X1Tag</hask> to <hask>X2Tag</hask> and then back to <hask>X1Tag</hask>, the <hask>a</hask> value should be the same as before (consider a complex value which is hard to re-create). Similar holds for the <hask>Char</hask> value. |
||

=== Generic ADT lens === |
=== Generic ADT lens === |

## Revision as of 22:32, 7 June 2013

## Contents |

## 1 Problem description

Lenses provide uniform and compositional way to view and edit data structures.

For example, one can view and edit pairs withq == setL fstLens (getL fstLens q) (setL sndLens (getL sndLens q) p)

Similarly, there is a toolbox of lenses for records which toolbox contains one lens for each record field.

Are there a toolbox of lenses for algebraic data types with multiple constructors?

## 2 Existing solutions

### 2.1 Partial lenses

The data-lens library provides partial lenses which are isomorphic to

type PartialLens a b = (a -> Maybe b, a -> Maybe (b -> a))

The flollowing partial lenses are defined for lists:

headLens :: PartialLens [a] a headLens = (get, set) where get [] = Nothing get (h:t) = Just h set [] = Nothing set (h:t) = Just (:t)

tailLens :: PartialLens [a] [a] tailLens = (get, set) where get [] = Nothing get (h:t) = Just t set [] = Nothing set (h:t) = Just (h:)

### 2.2 Other solutions

*Please help to extend the list of known solutions.*

## 3 ADT lenses

The proposed solution, summarized:

**As a lens toolbox for an ADT, use a lens whose codomain is the ADT and whose domain is tuple of the constructor tag and the ADT components.**

Let's see specific examples before the generic descripton of the proposed lens.

### 3.1 Example: List lens

The lens for lists which forms a complete toolbox:

import Data.Lens.Common

listLens :: Lens (Bool, (a, [a])) [a] listLens = lens get set where get (False, _) = [] get (True, (l, r)) = l: r set [] (_, x) = (False, x) set (l: r) _ = (True, (l, r))

#### 3.1.1 List lens usage

Suppose that we have a statetype S = (Bool, (Int, [Int]))

We can view and edit the list through the following lenses:

- edits thelistLens :: Lens S [Int]
**complete list**. - edits thefstLens :: Lens S Bool
**top level constructor**of the list:corresponds toFalseand[]corresponds toTrue.(:) - edits theheadLens = fstLens . sndLens :: Lens S Int
**head**of the list. - edits thetailLens = sndLens . sndLens :: Lens S [Int]
**tail**of the list.

Remarks:

- If the top level constructor of the list is , the head and the tail of the list can still be edited; the change will only be visible through[]when the constructor is changed back tolistLens. This may seem to be odd, but for many applications this is the right behaviour.(:)
- For editing the tail of the tail of the list, we need an such thats' :: Sviewed throughsis the same astailLensviewed throughs'. Explained on a figure:listLens

*references*. One possible definition of references is described in LGtk/Semantics#References. How

### 3.2 Example: ADT with repeated record fields

Consider the following ADT:

data X a = X1 { y :: Int, z :: a } | X2 { y :: Int, v :: Char }

For the ADT lens, first define an auxiliary enum type for the constructor tags:

data XTag = X1Tag | X2Tag

xLens :: Lens (XTag, (Int, (a, Char))) (X a) xLens = lens get set where get (X1Tag, (y, (z, _))) = X1 y z get (X2Tag, (y, (_, v))) = X2 y v set (X1 y z) (_, (_, (_, v))) = (X1Tag, (y, (z, v))) set (X2 y v) (_, (_, (z, _))) = (X2Tag, (y, (z, v)))

Remarks:

- Instead of , we could use(XTag, (Int, (a, Char)))or(XTag, (Int, a, Char))too. This is an implementation detail.(XTag, Int, a, Char)
- remembers the value ofxLensif we change between the constructor tags. This is the intended behaviour.y
- remembers the values ofxLensandvfields if we change between the constructor tags. This is the intended behaviour.z

#### 3.2.1 Interpreation

The intended behaviour can be justified if we interpret lenses as abstract editors. If we would like to define an editor of an- An elementary editor for (maybe a combo box or a checkbox) which would be connected to the editor state byXTag.fstLens
- An elementary editor for an (maybe a text box or a slider) which would be connected to the editor state byInt.fstLens . sndLens
- An editor for an typed value which would be connected to the editor state bya.fstLens . sndLens . sndLens
- An editor for a (maybe a combo box or a text box or a virtual keyboard) which would be connected to the editor state byChar.fstLens . sndLens . sndLens . sndLens

Now, the intended behaviour is the following:

- If the user fills in an value forInt, this value should remain the same after changing theyvalue.XTag
- The value editor should be active only if theavalue isXTag.X1Tag
- The editor should be active only if theCharvalue isXTag.X2Tag
- If the user fills in an value forawhen thezvalue isXTag, and the user changesX1TagtoX1Tagand then back toX2Tag, theX1Tagvalue should be the same as before (consider a complex value which is hard to re-create). Similar holds for theavalue.Char

### 3.3 Generic ADT lens

TODO

## 4 Links and references

I have not seen this technique described before. Please help to extend the list of papers / blog entries, where this or similar technique is used.

[Reddit comments]