search

tweag / linear-base

Standard library for linear types in Haskell.
MIT License
335 stars 37 forks source link

What should the composition operators for lens be? #129

Closed aspiwack closed 3 years ago

aspiwack commented 4 years ago

In linear-base, we took the decision of making Optic a newtype to improve on the error messages from the lens library. (While retaining the same spirit of subtyping-by-typeclass-subsumption. So not quite the same level of control as what the optics library aims for. Some kind of middle ground.)

A consequence is that we can't use the (.) as a lens composition operators: lenses are not functions. They do not even form a category, at least not naturally (you can form a category of optics where the objects are pairs of types, but we would have to make it apparent in the Optic types, which would have to take two pairs of types as arguments instead of 4 arguments, and we would need a general enough definition of category to make that stick. It's not strictly impossible but it's beyond the scope of linear-base).

We've been using the symbol (.>) for composition (my intuition was some sort of a mix between the . notation for records and the F♯/Ocaml pipe operator (|>) denoting sequence). But in the lens library, this particular symbol is also used, to mean the composition of a regular lens (to the left) with an indexed lens (to the right). So maybe using (.>) doesn't follow the principle of least surprise.

So this issue is to try and figure a better operator for optic (lens, prisms, traversals, …) composition.

mboes commented 4 years ago

Could be <.<: like (<<<) from Control.Arrow but also like (.). Could also have >.> by symmetry.

mboes commented 4 years ago

Or <<. and .>>

aspiwack commented 4 years ago

What does the optic library use, by the way?

utdemir commented 4 years ago

@aspiwack I think it mainly uses %, and comes with a few varieties of it: https://www.stackage.org/haddock/lts-16.13/optics-core-0.2/Optics-Optic.html#g:2

Divesh-Otwani commented 3 years ago

I think <<. and >>. are nice and since we are doing something a bit different, I feel OK with some new names.

aspiwack commented 3 years ago

We've gone with (.>) in 1.0. And I rather like it so, despite the unfortunate collision, let's close it for now.