... | ... | @@ -217,6 +217,11 @@ ugly TH splices with a nice deriving clause or would that need to be built in? |
|
|
An example of an advantage of using lens libraries: fclabels has a notion of "partial lenses" that can return Nothing. People who like that feature can have the lens deriver generate a partial lenses for `x` but a total lens for `y` in
|
|
|
`data R = R1 { x, y :: Int } | R2 { y :: Int }` which would solve the problem in a nice typesafe way rather than generating a `x` function that fails at runtime. If we have built in lenses, or a record system with a built-in way of generating record accessors (morally equivalent), then we are stuck with whatever choice was baked into ghc. Hopefully it's Maybe rather than runtime errors, but at least using an external lens library lets you retroactively fix things like that.
|
|
|
|
|
|
|
|
|
I (aavogt) wrote a preprocessor \<[ http://code.haskell.org/\~aavogt/recordlabel-preprocessor/perf.html](http://code.haskell.org/~aavogt/recordlabel-preprocessor/perf.html)\>, which uses \` instead of \#.
|
|
|
It takes a different perspective, in that \`x is just a way to write a type level string
|
|
|
`Symbol` "x", but that's only useful with extensible records. Regardless, user code seems to be very similar.
|
|
|
|
|
|
## pros
|
|
|
|
|
|
1. No effect on (.) operator, which is composition as always. No "binds tighter than functions" or left-to-right vs. right-to-left controversy, and partial application works as it always did. To compose lenses either hide the Prelude `(.)` and import the Category one, or just write your own lens composition operator and avoid all the `import hiding`.
|
... | ... | |