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

Scalaz 8 package organization #1540

Open
jdegoes opened this Issue Nov 28, 2017 · 22 comments

Comments

Projects
5 participants
@jdegoes
Member

jdegoes commented Nov 28, 2017

Proposed and preliminary package organization structure for Scalaz 8:

  • scalaz.algebra — Abstract algebra, including semigroup, magma, field, rng, etc.
  • scalaz.ct — Category theory, including functor, monad, & related.
  • scalaz.data — General-purpose data structures, such as These, etc.
  • scalaz.collections — General-purpose collections like heaps, trees, lists, maps, etc. This will probably be pulled out into a separate repository, with Scalaz 8 depending on it.
  • scalaz.ioz — IO monad, & things related to it, such as MVar, STM. Deprecated, this will be pulled out into a separate repo.
  • scalaz.effects — Type classes for effects, like MonadState, FunctorTell, etc.
  • scalaz.mutable — ST monad & related machinery for high-performance mutability.
  • scalaz.testz — Scalaprops & tests for everything. Deprecated, this has now become testz, although instances can and should still be defined in Scalaz 8.
  • scalaz.types — Leibniz, Liskov, IsCovariant, & friends.

A few things will have to be moved around.

@jdegoes jdegoes added the scalaz8 label Nov 28, 2017

@jdegoes jdegoes added this to To Spec in Scalaz 8 Nov 28, 2017

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 28, 2017

Could we get a quick description for each of these? Are you planning to build a testing framework? type == typeclass?
Will every package have some sort of Prelude?

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 28, 2017

@NeQuissimus Loosely based on this ticket.

I don't imagine each package would have its own prelude, just one prelude for the whole project.

As for testing framework, @xuwei-k has donated Scalaprops to Scalaz 8, and we could make some improvements on that similar to Hedgehog.

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 28, 2017

Ah, makes sense. And "thank you" to @xuwei-k !

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 28, 2017

"package" as a binary artifact (separate sbt project), or package in the sense of Scala?

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 28, 2017

@TomasMikula package in the sense of Scala.

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 28, 2017

I would like if the dependencies between packages formed an acyclic graph. Not sure if that's feasible. We could use lihaoyi/acyclic to enforce it.

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 28, 2017

👍

@Jacoby6000

This comment has been minimized.

Contributor

Jacoby6000 commented Nov 28, 2017

I think having a misc package is dangerous unless there are very clearly defined things which are miscellaneous. Usually it winds up just being a bucket of unrelated things which people were too lazy to find a good place for.

@vmarquez

This comment has been minimized.

Member

vmarquez commented Nov 28, 2017

@TomasMikula I'm not sure if that's possible or worth compromising for. Off the top of my head an example is the usefulness of having typeclass/syntax for data types, but also the fact that we want some type classes to return Maybe (which would live in Data).

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 28, 2017

@Jacoby6000 Fixed

@vmarquez the type classes can depend on the data package, and implement instances for them there (no orphans).

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 29, 2017

I'm not sure if that's possible

Yeah, it's likely impossible with the current outline. Data types certainly need typeclasses (e.g. IList needs a Monoid in foldMap), and, as you say, it would be convenient for typeclasses to use, say, Maybe.

But there could be a different partitioning into packages that is acyclic. The way the project evolves is acyclic: what we have now doesn't depend on anything that we will add tomorrow.

or worth compromising for.

Yeah, maybe it's not. Just accept that scalaz is a big monolith and subpackages are just approximate groupings by topic.

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 29, 2017

@jdegoes So what would be in scalaz.type? Things like Leibniz, Liskov, IsCovariant, ...?

Also, since type is a keyword, we would have to keep writing it as scalaz.`type`, so perhaps it's better to choose a different name.

Isn't mtl a misnomer (in that it's not about monad transformers)? Why keep perpetuating the confusion?

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 29, 2017

@TomasMikula Yes, I imagined things like Leibniz, etc., would fall in there. Perhaps typelevel?

mtl is definitely a misnomer. What would you suggest? Maybe effects and rename effect -> io?

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 29, 2017

I don't think typelevel is fitting to that content. It is rather opposite: things from the type level reified to the value level. Perhaps typesystem? Or just types?

mtl is enterprise-design-patterns. 😃 I guess effects would work, too :)

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 29, 2017

@TomasMikula Yes, but you can do some pretty interesting things with "runtime proofs" of type equivalence, which is what Leibniz gives you (e.g. GADTs). But I agree types is better. 👍

OK, I'll update the list now.

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 29, 2017

@TomasMikula @vmarquez @Jacoby6000 @NeQuissimus Any other comments here?

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 29, 2017

I'm somewhat skeptical that we can come up with a future-proof package structure (things will come up that fit equally well into two or more packages; which one do we choose then?), but scalaz 8 is experimental enough to give it a try.

@Jacoby6000

This comment has been minimized.

Contributor

Jacoby6000 commented Nov 29, 2017

This bit confuses me:

  • scalaz.algebra — Abstract algebra, including semigroup, magma, field, rng, etc.
  • scalaz.ct — Category theory, including functor, monad, & related.

I thought semigroup came from category theory

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 29, 2017

@Jacoby6000 No, semigroup is from abstract algebra, predates category theory by decades.

@TomasMikula Agreed. We can always shuffle things around or collapse them.

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 29, 2017

I think this package structure makes sense. I don't know that tests should be in a separate package. Generally, tests sit next to the class under test?!
Or is that not what "Tests for everything" is supposed to mean?

And once we have agreed on packages, we should all head to #1528 and agree on that. Then we should have the basic structure in place and can organize things...

@jdegoes

This comment has been minimized.

Member

jdegoes commented Nov 29, 2017

It's true that generally, tests will be in the same package. But we will be using scalaprops for testing, but scalaprops depends on Scalaz core. So we have to pull the tests out somewhere in a place that can depend on both scalaprops and Scalaz core.

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 29, 2017

Ah, that does make sense!

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