Scalaz 8 package organization #1540
Comments
Could we get a quick description for each of these? Are you planning to build a testing framework? type == typeclass? |
@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. |
Ah, makes sense. And "thank you" to @xuwei-k ! |
"package" as a binary artifact (separate sbt project), or |
@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. |
|
I think having a |
@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). |
@Jacoby6000 Fixed @vmarquez the type classes can depend on the data package, and implement instances for them there (no orphans). |
Yeah, it's likely impossible with the current outline. Data types certainly need typeclasses (e.g. 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.
Yeah, maybe it's not. Just accept that scalaz is a big monolith and subpackages are just approximate groupings by topic. |
@jdegoes So what would be in Also, since Isn't mtl a misnomer (in that it's not about monad transformers)? Why keep perpetuating the confusion? |
@TomasMikula Yes, I imagined things like
|
I don't think
|
@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 OK, I'll update the list now. |
@TomasMikula @vmarquez @Jacoby6000 @NeQuissimus Any other comments here? |
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. |
This bit confuses me:
I thought semigroup came from category theory |
@Jacoby6000 No, semigroup is from abstract algebra, predates category theory by decades. @TomasMikula Agreed. We can always shuffle things around or collapse them. |
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?! 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... |
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. |
Ah, that does make sense! |
Proposed and preliminary package organization structure for Scalaz 8:
These
, etc.testz
, although instances can and should still be defined in Scalaz 8.Leibniz
,Liskov
,IsCovariant
, & friends.A few things will have to be moved around.
The text was updated successfully, but these errors were encountered: