What obstacles are there to 'efficiently?'

I'm planning on implementing profunctor optics in a way that makes sense for Plutarch lenses.

• As much work should be done in Haskell, at Plutarch compile time.
• I need to ensure not to introduce superfluous pcon/pmatch into the body of combinators and lenses themselves.
• Is there a risk of redundant pcon/pmatch in a composition of optics, which the composition function needs to deal with? It doesn't seem obvious to me that there is.
• The general problem of redundant matches might be unsolvable in library, and may need an optimizer pass.

Are there any efficiency considerations I am missing?

Consider combining Lens' a b and Lens' a c into Lens' a (b, c). How do you this efficiently?
Relying on the backend to optimise it is not good design.

• Optics for EPair and EEither
• type aliases PLens and PPrism
• typeclass PChoice for PPrism
• some useful combintors in Core

We have optics!

• Plutarch-free profunctor and optics stacks based on the Cont monad - essentially replacing every a -> b with a -> Cont r b
• Optics for EPair and EEither. These essentially use Haskell Either in Plutarch!

Happy to change that back. I use partial-type-signatures warnings with HLS quite heavily in my workflow.
shell.nix on master has ghc923, which is what I'm using.

Not having r on the right of an arrow breaks a lot of inference and requires many type applications. In addition, something hard broke, I can't remember what. It seemed fixable, but not worth the trouble. I'm happy to try again if you think it's worth it.

PConstrained implemented

• Completed ptraverse for types with one parameter
• Implemented plist in terms of ptraverse

We won't really know if this works until we have a backend to test with.

Amazing! Perhaps we should work on getting a backend to work again.

Plutarch has changed too much for this to be mergible.