[Haskell-cafe] Lenses and records and ecosystem

[Anthony Clayden]

> 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