Re: [Haskell-cafe] Lenses and records and ecosystem
ON 10/02/17 07:10, Tony Morris wrote:
On 10/02/17 15:35, Anthony Clayden wrote: I see Simon PJ's comment here
https://github.com/ghc-proposals/ghc-proposals/pull/6#issuecomment-277971802
and the lengthy discussions from different advocates.
How much is it true there's a fractured "Haskell ecosystem" with 2 (3?) incompatible approaches: * H98 style labelled records with various extensions to ease the pain. * newtype-wrapped Lenses * 'raw' (unwrapped) Lenses
Yearss ago, many of us spent a long time on different designs of lenses, ... ... it would be foolish to concede that ground for no significant benefit.
Thanks Tony, but I don't understand: concede what ground? You're perhaps saying that one style of lenses is the 'right' one(?) I am asking if they can co-exist.
Can you mix those three styles inside one program? How much pain does it cause?
Can you import libraries with a mix of styles? How does a program cope?
Why would you? For what practical purpose? A lens/a structure/a record is a means to an end. Applications that are putting/getting stuff are doing it for some purpose. Not merely because lenses are a nice application of category theory. So say you want to use the functionality from 3 different libraries, but each is written using a different style.
I see the plethora of operators Lenses come with (mostly to keep the types coherent?). Except that Lens composition is plain function
composition
(.).
I remember something from SPJ's video/lecture on Lenses: that having Lens composition turn out to be function composition is "cute".
The use of (.) here was deliberately designed that way to assist in working against existing code.
Is "against" some clever pun here? Like Concerto for Piano against Orchestra? Certainly (.) for lenses works 'backwards' (i.e. suffix style) compared to function-prefix style. (As any Lens tutorial will say.)
That suggests to me it's more of a happy accident than a necessary feature.
Not necessary, just useful. I am less excited about this feature than many others, but it is useful nonetheless, and was specifically designed that way.
Whether or not that's justified [**] it's counter-intuitive w.r.t. Haskell, so I don't see a need to use the same symbol. Hence my "wondering" below.
I also see in the ORF proposal, OverloadedLabels part, that composing with Control.Category.(.) can lead to type ambiguity.
I wonder: Could there be a dedicated operator for composing Lenses, that has the same semantics as (.), but a more specialised type? To strengthen type inference/reduce ambiguity.
[**] the justification for postfix style seems to be so it's more like OO. Seems strange: FP just isn't very like OO. And in particular, functional data structures, just aren't like OO/procedural data structures. Anthony
On Fri, Feb 10, 2017 at 7:53 PM, Anthony Clayden < anthony_clayden@clear.net.nz> wrote:
Certainly (.) for lenses works 'backwards' (i.e. suffix style) compared to function-prefix style. (As any Lens tutorial will say.)
Those tutorials are oversimplifying. Lenses (and their relatives) transform
operations, not values. Composition of lenses is exactly like composition
of functions, with the inner-most operation on the right. A lens foo ::
Lens O I transforms an operation on I into an operation on O. A composition
outer.inner turns an operation on the target of inner into an operation on
the source of outer.
This is demonstrated by the way over distributes with (.):
over (outer . inner) = over outer . over inner
What confuses people is view, which is contravariant:
view (outer . inner) = view inner . view outer
but you can’t avoid having one of over and view be contravariant.
--
Dave Menendez
participants (2)
-
Anthony Clayden -
David Menendez