Skip to content

Instantly share code, notes, and snippets.

@julien-truffaut
Last active December 18, 2019 14:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save julien-truffaut/807a5ae4f18be41898fcae202e4fa310 to your computer and use it in GitHub Desktop.
Save julien-truffaut/807a5ae4f18be41898fcae202e4fa310 to your computer and use it in GitHub Desktop.
State of Monocle

Monocle, like many other Scala FP libraries, was inspired by Haskell. In our case, it is the Lens library by Edward Kmett and al.

In Monocle, we experimented with various optics encoding: pair of functions, Van Laarhoven, and profunctor (see LensImpl). The JVM and Haskell runtime are hugely different, and an encoding that works well in Haskell can be inefficient in Scala. For example, Haskell relies on zero cost wrapper (newtype) to effectively select typeclass instances, but we don't have an equivalent in Scala/JVM yet (opaque types may help). You can find some of the benchmarks we made for Lenses in 2015 here.

However, something we didn't do very well was to adapt the API to the specificity of Scala. If you look at Monocle 1.x or 2.x, it has the same interface as Haskell Lens but expressed in a much more clunky way. The example of this can be seen in optics composition, i.e. how we build complex optics out of simpler ones.

case class Person(name: String, address: Address)
case class Address(streetNumber: Int, postCode: String, county: Option[String])

// Assume we have address a Lens[Person, Address] and county a Lens[Address, Option[String]]

address . county . _Some // Haskell Lens
address.composeLens(county).composePrism(some) // Scala Monocle

They are two main reasons why Monocle doesn't have such a nice interface as Haskell Lens:

  • Optics in Lens are aliases for fancy functions, e.g. type Lens a b = functor f => (b -> f b) -> a -> f a. So optics composition is "just" function composition (. in Haskell). We cannot use this encoding in Scala 2; we would need polymorphic functions which we may have in Scala 3.

  • Almost all optics compose together (see table). We could define overloaded compose methods, one for each valid combination of optics. Unfortunately, there is a bug in Scala 2 that makes the type inference weaker with overloaded methods (see issue). There is an easy workaround; we can use non-overloaded compose methods, e.g. composeLens, composePrism, composeIso, etc. The type inference now works, but the API is much more verbose. Fortunately, Dotty fixed this issue so we can expect a single overloaded compose method in Monocle for Scala 3.

In September, I quicked out the development of a new major version for Monocle. The main goal of Monocle v3 is to make the API user-friendly. To do this, we will rewrite the library from scratch and try to leverage Scala features such as inheritance, class methods, and variance. More in my next post, stay tuned.

If you would like to participate in the development of Monocle, we are always looking for new contributors and active maintainers. You don't necessarily need to be an expert in optics. We also need help to create benchmarks, documentation, tutorials, and general API feedback.

@pvillega
Copy link

Comments:

Content: good, nothing missing or to add. You explain the issue and how it will be fixed. Links all work.

Style: minor comments

  • the sentence 'it has the same interface as Haskell Lens but in much more clunky way' sounds forced, maybe it is missing some word (but expressed in a much more clunky way?) or something.

Grammar: couple of minor things

  • there's a couple of instances of missing the and in an oxford coma (pair of functions, Van Laarhoven, profunctor; inheritance, class methods, variance)
  • reversely, missing ',' before and on the last sentence ( tutorials and general API feedback.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment