Having non/algebra depends on non/cats

[denisrosset]

If non/cats removes the non/algebra dependency, how should the non/algebra be continued ? Should non/algebra depend on non/cats, or a subset thereof ?

The original vision of non/algebra was to be free of dependencies. Should we introduce a dependency of cats, and then on cats dependencies such as simulacrum, type-projector and so on ?

What binary compatibility guarantees would then be offered ?

[rklaehn]

I think/hope the idea would be to depend on just a small subset of the cats typeclasses. See https://github.com/non/cats/issues/777 . The main additional dependency is simulacrum and type-projector. I agree that this needs to be sorted out ASAP.

[denisrosset]

Thinking of it, I guess both these dependencies are fine.

simulacrum does provide syntax in the companion object, but you are free to ignore it. type-projector is a syntax plugin which does not affect non/algebra that much anyways.

Everything is provided at compile-time, and does not require runtime dependencies.

But this should be checked with the algebird people, and the vision of non/algebra should be updated.

[denisrosset]

Still, I would require a statement from all dependencies of non/algebra that they provide trivial binary compatibility, i.e. libraries depending on different versions of them can be mixed freely, and that the projects that depend on non/algebra do not need to include these dependencies as well (only indirectly).

This would then remove roadblocks on the adoption of non/algebra in other projects, like algebird or breeze.

[non]

So, I'm not totally sure. I think we will need to see what Cats ends up doing and then decide independently.

If there is a small kernel of Cats that contains the overlap, then it's easy to imagine depending on Cats. Otherwise, I'm less certain. We had been talking about an algebra-kernel (to ease Cats' dependency woes) so I could also imagine the reverse.

One interesting question is the appetite of Twitter to make Algebird depend on Algebra and/or Cats. If they would be fine depending on a small subset of Cats, then that makes a dependency easier. (And if they aren't going to create an Algebra dependency either way it also makes things easier.)

[denisrosset]

Great, thank you.

[rklaehn]

I guess the idea of algebra-kernel is no longer necessary. What about the other modularization of algebra (core/lattice/ring)? Is that still necessary? At least spire is going to use all of it anyway.

The version that is currently on maven is still monolithic, right?

[johnynek]

Is there a link to the discussion to remove the algebra dependency? My reaction is that this is a bad idea or at least bad for the concept of the algebra project being a shared set of traits.

Algebird depending on cats is probably not going to happen (as algebird is depended on by a large number of things at Twitter and we'd be asking to increase all their dependencies by one more).

[johnynek]

Sorry, I see the link above.

It does not seem to have a motivation included. What is the motivation here?

It seems to me that cats might just want to depend on algebra-core (as that split has already happened).

[denisrosset]

@johnynek I would prefer personally that cats keep its dependency on algebra --- but I'm not active with cats at all. I opened this issue so that the position of non/algebra can be decided.

[rklaehn]

Here is the PR from @milessabin https://github.com/non/cats/pull/762 . @non gave his OK. I really don't care about who depends on what, as long as we have no duplication of typeclasses between cats and algebra. In any case, this needs to be sorted out if scala wants to be a viable platform for typeclass-based FP.

[johnynek]

I'm super bummed it by this: https://github.com/non/cats/pull/762 because how can we really expect this to be a useful common when not even cats wants to take a dependency.

I think it is very likely to harm adoption of the project. For instance, probably algebird should just copy what we want there since the mission of a common dependency looks to be failing and for people in large code bases, any dependency is already a cost and risk of future breakage (via diamonds, etc...)

[milessabin]

It's not that Cats won't take a dependency, it's that it's the wrong dependency ... Cats is the general purpose library, Algebra, at least in it's current form, is more than somewhat specialized. We'll do our best to ensure that there is a minimal stable Cats kernel module that you'll be able to depend on.

[denisrosset]

@milessabin : I disagree. Cats has many dependencies (simulacrum, kind-projector, machinist), while algebra has none.

[milessabin]

Exactly my point: Cats isn't resistant to appropriate dependencies. Algebra's resistance to dependencies on simulacrum, kind-projector and machinist is a problem because it means that the style of code for eg. Monoid in Algebra, and MonoidK in Cats, is very very different.