Optics

[L-as]

No description provided.

[MangoIV]

awesome resource (at least imho) :3
https://oleg.fi/gists/posts/2017-04-18-glassery.html

[AriFordsham]

Some opinions here:

I don't like the van Laarhoeven representation, although we should be able to avoid that here. You don't even lose the category instance, since we anyway use DataKinds: https://cstheory.stackexchange.com/a/51028/61454.

I particularly loathe implicit subtyping, which no lens implementation, including profunctor optics seems to avoid. I think 'composing' a lens with a prism should use an explicit operator marking it as tht.

I'm going to spend today seeing if I can come up with a lens representation that I like, otherwise I'll just pick the 'least worst' representation, probably profunctor optics.

[AriFordsham]

I think I'll stick with profunctors. I was making progress with my ideas, but I think it'll be too long until they're workable. I'll have to reinvent lenses some other time 😃.

So the idea is to implement profunctor optics in Plutarch, over Plutarch types. I see this as three stages:

• Implement profunctor optics (the interface) in Plutarch - no existing library will work, as the function type is different.
• Implement generic deriving of lenses for Plutarch datatypes.
• Ensure lens implementations are optimum, in terms of minimizing uses of pcon/pmatch.

Some questions:

• Should API design follow the profunctors paper? The optics library? Some other library?
• Lenses and prisms are presumably needed. What about isos and traversals?
• What considerations are there for Data/Scott encoded types?
• What considerations are needed to ensure implementation is optimal, as opposed to a naive implementation?

[L-as]

I'm not sure we can use any traditional optics representation.

• Doesn't matter, whatever is easiest
• Yep.
• Doesn't matter. This is plutarch-core.
• Merge uses of econ and ematch.