[Haskell-cafe] Lenses and records and ecosystem
anthony_clayden at clear.net.nz
Sat Feb 11 00:53:59 UTC 2017
> 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
>> and the lengthy discussions from different advocates.
>> How much is it true there's a fractured "Haskell
>> 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
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
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
>> 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
>> 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.
More information about the Haskell-Cafe