larsrh on revert-216-docs
larsrh on master
Revert "fix homepage (#216)" T… Merge pull request #220 from ty… (compare)
larsrh on v1.0.1
larsrh on master
Setting version to 1.0.1 Setting version to 1.0.2-SNAPSH… (compare)
johnynek on master
build for 2.13.0-M5 (#223) * b… (compare)
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.
Group[G].emptysyntax used to describe the identity element, instead of the mathematical
Group[G].id. But I'm not going to change the underlying
cats.kerneltypeclass. I'm going to add a short enrichment class to provide
Group[G].isId, and I don't need to break the binary compatibility -- in a sense I define partly my own syntax.
ARepwritten for GAP version 3. Because it's difficult to port
ARepto 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.
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.
Group[G].emptyexample I meant the following. When aligning
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.
algebrashould have a syntax on its own and not depend on
spireto provide it.
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
machinist, everything gets inlined)
discipline, the dependency on
scalacheckand the laws encoding a lot of structure.
I'll create a ticket, capture the discussion from here. A couple of comments:
Is there a problem of duplicating the
cats-coresyntax 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..?
cats-kernel, the pace of change will be glacial: there is a commitment to preserve binary compatibility across minor releases.