These are chat archives for non/algebra

7th
Jan 2017
Denis Rosset
@denisrosset
Jan 07 2017 02:59
@benhutchison If there is a way to make the cats-core dependency compile-time only, sure.
(That's the great thing about machinist, everything gets inlined)
P. Oscar Boykin
@johnynek
Jan 07 2017 03:00
I’m fine with anything that is using mima and is taking binary compatibility seriously.
every release of cats breaks binary compatibility.
it’s a bummer.
It’s great to have pretty code, but constant breakage makes migrations painful, and I need to use this code in large code-bases.
Denis Rosset
@denisrosset
Jan 07 2017 03:05
@benhutchison Is there a problem of duplicating the cats-core syntax code in algebra? Otherwise we need source and binary compatibility from machinist as well.
P. Oscar Boykin
@johnynek
Jan 07 2017 03:06
I don’t mind duplicating code too much, if it is syntax, without much logic and in its own namespaces.
Denis Rosset
@denisrosset
Jan 07 2017 03:06
Agree.
But having a syntax module in algebra is great.
P. Oscar Boykin
@johnynek
Jan 07 2017 03:08
I’m not a big syntax guy.
Denis Rosset
@denisrosset
Jan 07 2017 03:10
Actually, what is the use case of algebra syntax? Most people will use algebird or Spire to do anything useful anyway.
P. Oscar Boykin
@johnynek
Jan 07 2017 03:10
Maybe, but I think the scope of Algebra is growing.
like spire has many great types as does algebird.
but if you want to make a new monoid, you might just depend on Algebra.
and in that case, you might want syntax
(actually, in that case you would use cats-kernel, I think)
but if you wanted rings or fancy lattices. :)
Denis Rosset
@denisrosset
Jan 07 2017 03:12
Indeed, for example a library for fixed point numbers.
OK, I'm not an algebra maintainer; but I would suggest @benhutchison to open an issue to have the maintainers validate the plan before doing too much work.
P. Oscar Boykin
@johnynek
Jan 07 2017 03:14
+1 to an issue so @non @tixxit and others can weigh in.
Denis Rosset
@denisrosset
Jan 07 2017 03:15
We will have the same discussion about the law tests; should cats/algebra/spire have independent modules, or should we have a dependency chain? The matter is much more complex there, with the use of discipline, the dependency on scalacheck and the laws encoding a lot of structure.
P. Oscar Boykin
@johnynek
Jan 07 2017 03:16
yeah, we can have that discussion. I all for sharing when we have some commitment and track record of binary compatibility.
Denis Rosset
@denisrosset
Jan 07 2017 03:16
Indeed, track record. The Scala ecosystem is pretty young!
P. Oscar Boykin
@johnynek
Jan 07 2017 03:17
I think we are actually in a maturing phase at the moment.
Denis Rosset
@denisrosset
Jan 07 2017 03:17
Indeed; there is still a conflict between purists and pragmatists (by that, I mean people who ship large FP codebases, not the Scala-as-better-Java).
That makes the situation interesting to balance.
That said, I'm very excited about using Scala for computer algebra. Most CAS nowadays are using dynamic languages; while Scala runs on a performant VM and makes refactoring quite trivial in comparison.
Indeed we are in a maturing phase. I'm happy to contribute to some design corrections (like the GCD and EuclideanRing stuff), so that our building blocks approximate the mathematical structures as closely as possible...
Denis Rosset
@denisrosset
Jan 07 2017 03:23
... before it's too late. For example, most languages do not distinguish between Euclidean division and truncated division; then you are stuck with ambiguous syntax.
Ben Hutchison
@benhutchison
Jan 07 2017 09:45

I'll create a ticket, capture the discussion from here. A couple of comments:

Is there a problem of duplicating the cats-core syntax code in algebra?

Its code duplication. We'd end up with 2 copies of the same code to solve the same problems. Over time they can diverge, leading to slightly different syntax depending where you imported from.

To me its a fallback option. I'd prefer to try tackle the root problem and migrate the cats-kernel syntax into kernel where it belongs. only if thats intractable then resort to code duplication.

Otherwise we need source and binary compatibility from machinist as well.

Machinist is a bit special though, its macro generators rather than another library. I think its pretty stable, unlikely to be an problem...?

every release of cats breaks binary compatibility.

Are you referring to kernel, or cats core?

Cats-core is pre 1.0. My read of the consensus feeling from the community is that binary compat pre-1.0 is less important than "getting it right". After 1.0 the pace of change will slow - thats the stated plan IIUC..

As a maintainer of big codebases you probably feel the impact more than most. But if you're building atop pre-1.0 software you signed up to that to some degree..?

Denis Rosset
@denisrosset
Jan 07 2017 13:13
After 1.0 the pace of change will slow - thats the stated plan IIUC..
For cats-kernel, the pace of change will be glacial: there is a commitment to preserve binary compatibility across minor releases.
I don't know the situation for machinist. It's pretty stable, sure, but what is the commitment and what is the track record of that dependency? Code duplication is a minor problem compared to the diamond problem of dependencies.