Are there any real cases that the polymorphism of Control.Category..
becomes a real problem? I think ambiguity rarely occurs on the kind (* -> *
-> *).
2017-02-10 14:35 GMT+09:00 Anthony Clayden
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
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?
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 _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.