[Haskell-cafe] Lenses and records and ecosystem

[Anthony Clayden]

> 2017-02-11 09:30 UTC Fumiaki Kinoshita:

> Are there any real cases that the polymorphism of
> Control.Category.. becomes a real problem? I think
> ambiguity rarely occurs on the kind (* -> * -> *).
>

Hi Fumiaki, the remark is here
https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst#Example_of_ambiguity_under_IsLabel_interpretation

The composition is:
    fooBar = #foo . #bar
    ...
    However, if labels are interpreted using IsLabel, the
inferred type of fooBar is

    (Category cat, IsLabel "foo" (cat s t), IsLabel "bar"
(cat r s)) => cat r t

There's no FunDep on IsLabel (nor could there be).
So `s` is ambiguous. Same as the classical (show . read).
 
The usual type for raw/unwrapped Lenses is:

    type Lens s t a b = forall f. Functor f => (a -> f b) ->
(s -> f t)

Which is of kind (* -> * -> *), but you need to squint a
bit.

> > 2017-02-10 14:35 GMT+09:00 Anthony Clayden:
> > 
> >
> > 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".
> > That suggests to me it's more of a happy accident than a
> > necessary feature.
> >
> > 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.
> >

AntC