Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 03:07
    SethTisue commented #219
  • Jan 30 2019 21:49
    keithschulze starred typelevel/algebra
  • Jan 30 2019 20:19

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 20:11

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 19:56

    larsrh on revert-216-docs

    (compare)

  • Jan 30 2019 19:56

    larsrh on master

    Revert "fix homepage (#216)" T… Merge pull request #220 from ty… (compare)

  • Jan 30 2019 19:56
    larsrh closed #220
  • Jan 30 2019 19:55
    larsrh commented #219
  • Jan 30 2019 19:55
    larsrh closed #219
  • Jan 30 2019 19:55

    larsrh on v1.0.1

    (compare)

  • Jan 30 2019 19:55

    larsrh on master

    Setting version to 1.0.1 Setting version to 1.0.2-SNAPSH… (compare)

  • Jan 30 2019 18:05

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 17:54

    johnynek on master

    build for 2.13.0-M5 (#223) * b… (compare)

  • Jan 30 2019 17:54
    johnynek closed #223
  • Jan 30 2019 16:41
    sungjk starred typelevel/algebra
  • Jan 30 2019 14:28
    erikerlandson commented #223
  • Jan 30 2019 13:58
    tusharbihani starred typelevel/algebra
  • Jan 30 2019 13:39
    larsrh commented #223
  • Jan 30 2019 13:37
    erikerlandson commented #223
  • Jan 30 2019 13:30
    larsrh commented #223
Ben Hutchison
@benhutchison

When you "take stock" of what syntax in Spire could be moved to Algebra, it becomes evident that a huge piece of it comes from kernel and not from Algebra.

To the point that there's little point trying to add Algebra syntax without first moving Kernel syntax somewhere that Algebra could reuse it.

Doing that amounts to a migration within cats, adding a syntax package to kernel and adding redirects from cats core.

If there's a takeaway lesson from this, its: if you care about syntax, keep it with the relevant typeclasses
Denis Rosset
@denisrosset
@benhutchison, I respectfully disagree. Algebra is all about compatibility of typeclasses, so it should be as small as possible. The compatibility guarantees proposed for cats-kernel are very good in that sense: binary compatibility across patch and minor versions.
This is especially relevant when dealing with numerical/mathematical code, where you often find libraries that have not been maintained for years.
(Because it was written for a PhD thesis, and the author left academia long ago, for example)
But the binary compatibility of syntax is actually a different story: because everything happens using macros, there are no runtime dependencies for those JARs. Having a syntax module in algebra is a very good idea; let's put it in a different module, and if possible we tag the corresponding JAR as compile-time only (if there is such a possibility). Then we never need to worry about binary compatibility.
Algebra is going to be the root of many diamonds in the JAR hell.
Denis Rosset
@denisrosset
To give one example: I disagree with the Group[G].empty syntax used to describe the identity element, instead of the mathematical Group[G].id. But I'm not going to change the underlying cats.kernel typeclass. I'm going to add a short enrichment class to provide Group[G].id and Group[G].isId, and I don't need to break the binary compatibility -- in a sense I define partly my own syntax.
For the source/binary compatibility story, a good example is the package ARep written for GAP version 3. Because it's difficult to port ARep to GAP version 4, several research groups choose to maintain the whole GAP 3 computer algebra system (dating from 1997!) and provide builds for recent Linux distributions.
Ben Hutchison
@benhutchison

Algebra is all about compatibility of typeclasses, so it should be as small as possible.

@denisrosset We're in alignment that typeclass compat is important, I dont think Im proposing anything that contradicts that. But that's not all algebra could be about. It could, should IMO, also be useful in its own right.

And every useful typeclass lib in Scala ends up needing syntax enrichment. So if you leave syntax out of either Algebra or Cats Kernel we in effect say, "these libraries must be wrapped within another to be useful".

My position is that we should recognize, based on 10s of examples now, that useful Scala typeclass libs consist of 3 parts: typeclasses themselves, common instances, and syntax to enable infix and postfix operators. Keep the parts together! I see a tendency to treat syntax as a second class citizen, but in practice all the usage I see in the wild assumes syntax is enabled.

I didnt see the relevance of your Group[G].empty example to syntax, since the empty operator isn't provided via syntax but is on the typeclass?

To be clear, when Ive said "syntax" above I specifically refer to enrichment via implicit conversion to enable infix and postfix operators defined on the datatypes of the typeclass. Not "surface syntax" more generally.

Denis Rosset
@denisrosset
By the Group[G].empty example I meant the following. When aligning algebra to cats, the identity element was renamed the empty element. This makes perfect sense when dealing with monoids such as list or concatenation, but renders group theoretical code difficult to read. For me this is not a big deal, as avoiding typeclass fragmentation is my number #1 goal. By not having the syntax in algebra, I can implement my own infix/postfix operators, as you defined.
While typeclass fragmentation is extremely bad (see the scalaz/cats split), syntax fragmentation is not a big deal for me, as it does not impair interoperability.
Still, I understand your viewpoint: algebra should have a syntax on its own and not depend on cats or spire to provide it.
But for me, the first and foremost goal is to preserve binary compatibility at all costs, even across minor releases. Algebra is simply too low on the dependency chain to afford to break all the libraries that depend on it at every minor version bump.
Denis Rosset
@denisrosset
(I'd like to have algebra syntax optional - i.e., nothing in companion objects - and possibly in a separable JAR)
Ben Hutchison
@benhutchison

The syntax module would carry a dependency on cats-core (for the reasons described above), and it would only "make sense" if Spire reused it. So the dependency on cats core would extend to Spire.

By not having the syntax in algebra, I can implement my own infix/postfix operators, as you defined.

Re above, I don't think syntax in algebra would or could compromise your ability to enrich Group with an id alias for empty if desired. The kind of syntax Im proposing would enrich data values (only) with typeclass operations

Denis Rosset
@denisrosset
@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
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
@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
I don’t mind duplicating code too much, if it is syntax, without much logic and in its own namespaces.
Denis Rosset
@denisrosset
Agree.
But having a syntax module in algebra is great.
P. Oscar Boykin
@johnynek
I’m not a big syntax guy.
Denis Rosset
@denisrosset
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
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
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
+1 to an issue so @non @tixxit and others can weigh in.
Denis Rosset
@denisrosset
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
yeah, we can have that discussion. I all for sharing when we have some commitment and track record of binary compatibility.
Denis Rosset
@denisrosset
Indeed, track record. The Scala ecosystem is pretty young!
P. Oscar Boykin
@johnynek
I think we are actually in a maturing phase at the moment.
Denis Rosset
@denisrosset
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
... 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

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