larsrh on gh-pages
updated site (compare)
larsrh on gh-pages
updated site (compare)
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)
larsrh on gh-pages
updated site (compare)
johnynek on master
build for 2.13.0-M5 (#223) * b… (compare)
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 scalacheck
and 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-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..?
cats-kernel
, the pace of change will be glacial: there is a commitment to preserve binary compatibility across minor releases.