Package maintainers and Hackage trustees are allowed to edit certain bits
of package metadata after a release, without uploading a new tarball.
Note that the tarball itself is never changed, just the metadata that is
stored separately. For more information about metadata revisions, please
refer to the
Hackage Metadata Revisions FAQ.
| No. |
Time |
User |
SHA256 |
| -r3 (app-lens-0.1.0.0-r3) |
2015-09-03T05:15:24Z |
kztk |
ad87bfb247b35e26e965582ae05b62da4be7747e521a3df18fa51406de88c02e
|
|
Changed description
from A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
> >>> ["banana", "orange", "apple"] ^. unlinesL
> "banana\norange\napple\n"
> >>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
> ["Banana","Orange","Apple"]
One may prefer to define @unlinesF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unlinesF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
/Remark/.
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.
to A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
> >>> ["banana", "orange", "apple"] ^. unlinesL
> "banana\norange\napple\n"
> >>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
> ["Banana","Orange","Apple"]
One may prefer to define @unlinesF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unlinesF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
/Remark/.
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.Changed the library component's library dependency on 'base'
from >=4.7 && <4.8
to >=4.7 && <4.9 Changed the library component's library dependency on 'lens'
from >=4 && <4.12
to >=4 && <4.13 Changed the library component's library dependency on 'mtl'
from >=2.2 && <2.3
to >=2.2 && <2.4 Changed the benchmark 'compositions' component's library dependency on 'deepseq'
from >=1.3 && <1.4
to >=1.3 && <1.5 Changed the benchmark 'eval' component's library dependency on 'deepseq'
from >=1.3 && <1.4
to >=1.3 && <1.5
|
| -r2 (app-lens-0.1.0.0-r2) |
2015-07-01T23:21:21Z |
kztk |
29d9e8cabf54f27b1ccf007530fe698c0895c0bb6a2a6da50b71fafd4c27bd6d
|
|
Changed description
from A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
> >>> ["banana", "orange", "apple"] ^. unlinesL
> "banana\norange\napple\n"
> >>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
> ["Banana","Orange","Apple"]
One may prefer to define @unliftF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unliftF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
/Remark/.
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.
to A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
> >>> ["banana", "orange", "apple"] ^. unlinesL
> "banana\norange\napple\n"
> >>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
> ["Banana","Orange","Apple"]
One may prefer to define @unlinesF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unlinesF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
/Remark/.
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.
|
| -r1 (app-lens-0.1.0.0-r1) |
2015-06-16T06:00:41Z |
kztk |
a143bd5aec7a06285e0ef56e76f31e0d8b69f277da57ce4d88a7688355ca86a6
|
|
Changed description
from A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
>>> ["banana", "orange", "apple"] ^. unlinesL
"banana\norange\napple\n"
>>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
["Banana","Orange","Apple"]
One may prefer to define @unliftF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unliftF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
=== Remark
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.
to A bidirectional transformation connects data in difference formats,
maintaining consistency amid separate updates. The "lens"
programming language---with Kmett's Haskell lens package being
one of the most influentials---is a solution to this problem.
Many lens implementations (including Kmett's Haskell library) only
support the point-free style of programming. Though concise at times,
this style becomes less handy when programs get more complicated.
This module provides the infrastructure for programming complex
bidirectional transformations, by representing lenses as functions
that are subject to the normal applicative-style programming. For
example, let us consider the 'unlines' functions and to define a
lens version of it. In our framework we can program through pattern
matching and explicit recursion as in normal functional programming.
> unlinesF :: [L s String] -> L s String
> unlinesF [] = new ""
> unlinesF (x:xs) = catLineF x (unlinesF xs)
> where catLineF = lift2 catLineL
Here, @lift2 :: Lens' (a,b) c -> (forall s. L s a -> L s b -> L s
c)@ and @new :: a -> (forall s. L s a)@ lift lenses to functions.
The former is for binary lenses and the latter is for constant
lenses. We can then apply lenses as functions, alleviating the
need of specialized combinators. In the above, we omitted the
definition of a primitive lens @catLineL :: Lens' (String, String)
String@ that concatenates two strings with a newline in between.
Simply unlifting ('unlift', 'unlift2', 'unliftT') such "lens functions"
gives us the desired lenses.
> unlinesL :: Lens' [String] String
> unlinesL = unliftT unlinesF
The obtained lens works as expected.
> >>> ["banana", "orange", "apple"] ^. unlinesL
> "banana\norange\napple\n"
> >>> ["banana", "orange", "apple"] & unlinesL .~ "Banana\nOrange\nApple\n"
> ["Banana","Orange","Apple"]
One may prefer to define @unliftF@ with 'foldr'. Indeed, we can
use 'foldr' as below because @catLineF@ and @unlinesF@ are simply
Haskell functions.
> unliftF = foldr (lift2 catLineL) (new "")
Here, the program is written in a point-free manner similar to that
of the other lens frameworks. But note that this 'foldr' is just
Haskell's 'foldr', instead of a special combinator for lenses.
More examples can be found at \"Examples\" in the source code
<https://bitbucket.org/kztk/app-lens/downloads>.
/Remark/.
The applicative-style programming is possible in our implementation
because a function representation different from Kmett's is used for lenses.
As a result, when we program record-field access chains such as
> src .^ l1 . l2
> src & l1 . l2 .~ tgt'
The order of composition is inverted in our implementation.
> src .^ unlift (lift l2 . lift l1)
> src & unlift (lift l2 . lift l1) .~ tgt'
This difference causes slight inconvenience for record updates, but is
crucial in allowing the applicative-style lens programming we
aim for.
|
| -r0 (app-lens-0.1.0.0-r0) |
2015-06-16T05:27:21Z |
kztk |
35a639608f58b6d37f14c52b32e6f039ae5de5e32a5d1116b98b5ea20838530b
|
|
|