Eventual fate of the Dhall.Optics module

[quasicomputational]

I think it's a bit silly for dhall to have its own mini-lens - it's a violation of the separation of concerns. At the same time, the combinators are useful, and avoiding a dependency on lens does have value.

Possible directions:

• Do nothing; the situation isn't terrible. A few combinators being copy-pasted isn't the worst thing.

• Bite the bullet and incur a lens dependency. dhall is already a heavy package and I think the lens dependency only amounts to a few additional packages (there's already a dependency on profunctors, though not on semigroupoids), though lens itself is a meaty compile. The upside is getting to use all the fun things in lens.

• Try to get the combinators upstreamed into lens-family-core, which is already a dependency. I don't know how receptive that package is to implementing combinators from lens.

• Move to microlens instead of lens-family-core. This package definitely does accept random combinators from lens, and it's similarly lightweight. I don't know whether lens-family-core might have some countervailing advantage, though.

[Gabriella439]

Let's try getting the combinators into microlens, then

[quasicomputational]

I had a brief look at this and the sticking point is that half the combinators use profunctors, directly or indirectly. microlens-profunctor doesn't currently exist but it apparently will soon, so that'll be when we can have another look.

[Gabriella439]

@quasicomputational: I don't think we need profunctors, though, except for efficiency. The only thing we use it for in the module is (#.), which could be replaced with (.) (and coerce, if necessary for efficiency)

[Gabriella439]

I'm closing this unless somebody volunteers to implement this. I personally don't mind keeping the Dhall.Optics module around

[mmhat]

I am interested in a proper solution to this issue; Reopening.

[winitzki]

I'm not familiar with the Haskell ecosystem and with the ways the Haskell community is doing things with libraries and modules. I'm only familiar with the idioms of pure functional programming to the extend it is language-independent. So let me just say that in my view, libraries implementing profunctors, monoids, optics, etc. are specified uniquely through the mathematical properties of those data types. There should be no difference between any implementations of monoids or profunctors; there can be only one implementation. So, a program could depend on these libraries or copy their definitions; there won't be any significant difference, because the mathematical definitions of profunctors, monoids, lenses, etc. will literally never be revised, and the implementation follows automatically from the mathematical defiitions.

An exception would be if a library uses some complicated low-level code for better performance but still exposes the same high-level interface. It's hard for me to imagine how this could be the case for profunctors or lenses though.