[Haskell-cafe] Lenses and records and ecosystem
anthony_clayden at clear.net.nz
Sat Feb 11 11:20:08 UTC 2017
> 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
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
> > 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.
More information about the Haskell-Cafe