Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monocle 3 #714

Open
julien-truffaut opened this issue Sep 29, 2019 · 20 comments
Open

Monocle 3 #714

julien-truffaut opened this issue Sep 29, 2019 · 20 comments
Labels
V3

Comments

@julien-truffaut
Copy link
Owner

@julien-truffaut julien-truffaut commented Sep 29, 2019

Here is a couple of ideas I have for the next major version of Monocle:

  1. Have a small and very stable core (e.g. optics + laws + typeclasses + instances, no syntax). It would allow other libraries to safely depend on Monocle instead of introducing their own optics (e.g. doobie).
  2. Offer more friendly syntax for common cases, e.g. lens[Foo](_.bar.fizz).some.at("hello"). Dot syntax makes it discoverable by IDE, and it is concise.
  3. Move away from personal repo to an organisation. I want to find other active maintainers and give them admin rights.
  4. Use inheritance between optics to simplify conversions (e.g. Lens extends Optional)
  5. Remove polymorphic optics

We could also go further with 1) and try to have a 0-dependency core. It will probably be a problem for Traversal because we use Van Laarhoven encoding.

Please let me know what you think and if you have other ideas. Also, let me know if you would like to become a maintainer.

@cquiroz

This comment has been minimized.

Copy link
Collaborator

@cquiroz cquiroz commented Sep 29, 2019

A 0 dependency core would be a great objective. I think for example scalajs-react could benefit form that

I'd like to help as maintainer though I haven't contributed that much in the past. I'm a heavy Monocle user though

@mmynsted

This comment has been minimized.

Copy link

@mmynsted mmynsted commented Sep 29, 2019

I like idea 1. If you can reach a zero dependency core, so much the better.

@neko-kai

This comment has been minimized.

Copy link

@neko-kai neko-kai commented Oct 1, 2019

re: zero dependency core, Optional instances can be used to provide typeclass instances in separate modules without burdening users with wildcard imports, see https://blog.7mind.io/no-more-orphans.html

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 1, 2019

Thanks @neko-kai that might be useful to provide typeclass instance for cats or other data structure.

For reference, the main issue I see with the 0 dependency core is around Traversal encoding. We use the Van Laarhoven encoding where all Traversal methods are implemented in term of modifyF:

def modifyF[F[_]: Applicative](f: A => F[B])(s: S): F[T]
@jdegoes

This comment has been minimized.

Copy link
Contributor

@jdegoes jdegoes commented Oct 2, 2019

Please zero dependency! 🙏

And I'll volunteer to help on the architecture if my help is desired... and if not just say so, no need for the ban hammer! 😆 🙏

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 2, 2019

All help is welcome, John :)

@jdegoes

This comment has been minimized.

Copy link
Contributor

@jdegoes jdegoes commented Oct 3, 2019

Should I contribute here or somewhere else?

I have sketches of the following:

  • subtyping across optics
  • variance within optics
  • optic combinators
  • zero-dependency formulation of modifyF, among others

which may or may not be useful.

Excited about this!

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 3, 2019

@jdegoes I created a 3.x branch with a kernel module (0-dependency so far) to start playing with various encoding and proposals (See https://github.com/julien-truffaut/Monocle/tree/3.x/kernel/shared/src/main/scala/monocle)

Feel free to send PR or sketch your proposals here. Looking forward to seeing what you have in mind.

@mpilquist

This comment has been minimized.

Copy link

@mpilquist mpilquist commented Oct 4, 2019

I'd much prefer keeping a cats-core dependency. I've been maintaining interop libraries for years and find it very hostile to users. Unifying libraries like http4s, fs2, & doobie on the same base libraries massively simplified adoption. I'm considering moving the other direction these days, and removing interop libs in favor of dependencies on cats-core and cats-effect (e.g. for scodec).

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 4, 2019

Thanks for sharing your experience @mpilquist I am also worried it will cause maintenance headache and more imports to end-users. I think it is worth to give it a try.

@tpolecat

This comment has been minimized.

Copy link
Contributor

@tpolecat tpolecat commented Oct 4, 2019

Looks like you're abandoning the polymorphic variants, which seems reasonable to me. They have never seemed all that useful in Scala, and the drudgery kept me from reaching activation energy for an extension library to support split morphisms (which I still want to do).

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 4, 2019

@tpolecat I am not 100% committed on abandoning polymorphic optics but I think they are not really useful in Scala because of type inference. It is good to know monomorphic optics would help you with split morphisms (I really liked your presentation).

@tpolecat

This comment has been minimized.

Copy link
Contributor

@tpolecat tpolecat commented Oct 4, 2019

There's no reason it wouldn't work with the polymorphic design, I was just too lazy to implement them that way ;-)

@jdegoes

This comment has been minimized.

Copy link
Contributor

@jdegoes jdegoes commented Oct 5, 2019

@julien-truffaut Can't wait! I'll do a PR in the next few days.

modifyF is really the only reason for Applicative (= dependency on FP lib), once that goes away, you're into 0-dependency territory, which as I've found with ZIO, massively amplifies adoption and enables people to freely and independently upgrade libraries.

@nafg

This comment has been minimized.

Copy link

@nafg nafg commented Oct 6, 2019

I'm pretty sure I've needed polymorphic versions, although it's possible I missed a way to do what I wanted with monomorphic. That said, the fact that monomorphic optics are just type aliases to the polymorphic equivalents which are much harder to understand made the learning curve much steeper. I don't have a good suggestion.

@smarter

This comment has been minimized.

Copy link

@smarter smarter commented Oct 6, 2019

I am not 100% committed on abandoning polymorphic optics but I think they are not really useful in Scala because of type inference.

Do you have an example of the kind of type inference issue you run into ?

@sideeffffect

This comment has been minimized.

Copy link

@sideeffffect sideeffffect commented Oct 6, 2019

If it could serve as inspiration for the new design, there's a new optics library for Haskell
http://www.well-typed.com/blog/2019/09/announcing-the-optics-library/
it builds on, but simplifies the famous lens

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 7, 2019

@smarter I guess the problem is linked to the eagerness of scala type inference. For example, if you take pSome: PPrism[Option[A], Option[B], A, B] (https://github.com/julien-truffaut/Monocle/blob/master/core/shared/src/main/scala/monocle/std/Option.scala#L8). You can often infer A from context (e.g. you are updating an Option[Foo]) but B will depend on set or modify which are methods on the final optic (after everything is composed).

If dotty has polymorphic functions, the issue might be fixed.

@julien-truffaut

This comment has been minimized.

Copy link
Owner Author

@julien-truffaut julien-truffaut commented Oct 29, 2019

I tried to experiment with variance in optics, in particular, I tried to make the first type parameter contravariant. I couldn't make it work. I am curious if anyone has a POC of optics with variance.

@jdegoes

This comment has been minimized.

Copy link
Contributor

@jdegoes jdegoes commented Nov 6, 2019

Incoming shortly... (Sorry for the delay)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.