Scalaz 8 package organization

[jdegoes]

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.

[NeQuissimus]

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]

@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]

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

[TomasMikula]

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

[jdegoes]

@TomasMikula package in the sense of Scala.

[TomasMikula]

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]

👍

[Jacoby6000]

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]

@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]

@Jacoby6000 Fixed

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

[TomasMikula]

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]

@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]

@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]

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]

@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]

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

[TomasMikula]

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 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]

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

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

[NeQuissimus]

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]

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]

Ah, that does make sense!