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