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/pr... 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