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 <anthony_clayden@clear.net.nz>:
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.