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
Erik Osheim
@non
uh oh.
@denisrosset looks like it was meant to extend RingFunctions -- do you want to submit a PR? should i?
Denis Rosset
@denisrosset
Done.
Erik Osheim
@non
thanks!
Denis Rosset
@denisrosset
(Should have tests, though.)
Erik Osheim
@non
yeah, agreed.
Erik Osheim
@non
hey folks, just released algebra 0.6.0 -- here's a PR to update the README: typelevel/algebra#189
Srepfler Srdan
@schrepfler
:clap:
Sam Ritchie
@sritchie
typelevel/algebra#193
PR to create a microsite
I’ve also got one out to create a benchmarking project
Sam Ritchie
@sritchie
@non any idea why mima is reporting binary incompatibility for methods only present in the new version?
that doesn’t matter pre 1.0… I don’t see any way of hinting to mima, and thought it did this automatically
or maybe this is legit
[error]  * method defaultFromDouble(Double,algebra.ring.Ring,algebra.ring.MultiplicativeGroup)java.lang.Object in trait algebra.ring.RingFunctions is present only in current version
[error]    filter with: ProblemFilters.exclude[ReversedMissingMethodProblem]("algebra.ring.RingFunctions.defaultFromDouble")
[info] core: found 1 potential binary incompatibilities while checking against org.typelevel:algebra_2.11:0.6.0
[error]  * method defaultFromDouble(Double,algebra.ring.Ring,algebra.ring.MultiplicativeGroup)java.lang.Object in trait algebra.ring.RingFunctions is present only in current version
[error]    filter with: ProblemFilters.exclude[ReversedMissingMethodProblem]("algebra.ring.RingFunctions.defaultFromDouble”)
Sam Ritchie
@sritchie
yup, added info to the ticket
Ghost
@ghost~529c6cf4ed5ab0b3bf04da61
@sritchie Microsite looks cool!
Sam Ritchie
@sritchie
@larsrh thanks!
Ben Hutchison
@benhutchison

With a bit more free time in the xmas break period, Im circling back to the question of Algebra syntax

I personally think for Algebra to be useful/used standalone it needs syntax.

It seems that most syntax for algebra typeclasses already exists but is in Spire.

Presumably ideally migration for syntax into Algebra would be completely source-compatible for Spire users? I guess this is achievable, if all the Syntax traits in Spire (which users import) referenced the migrated syntax traits in Algebra.

Or does anyone prefer a conscious break in compatibility, where users have to fix their imports to upgrade to the migrated version? To me, this is an option of last resort, although it does mean less redirection in the codebase..

Tom Switzer
@tixxit
Assuming it followed a spire style syntax pattern (eg *Syntax traits that contains the implicits), I don't see why we couldn't provide source compatibility. So it seems a nice thing to have
Ben Hutchison
@benhutchison
@johnynek If Algebra included opt-in syntax based on Spire, it seems Algebird users would be unaffected providing they didn't import both Algebra syntax and Algebird operators together.
Denis Rosset
@denisrosset
@benhutchison @tixxit Does using syntax make any difference for the binary compatibility story? What is the binary compatibility story of algebra anyway? Should every dependency in a project be tied to a specific algebra release?
(I have no experience of Scala in a team environment; my projects are all based on a platform pinned on specific releases of cats/spire/scalatest/scalacheck/shapeless, thus avoiding jar hell)
Denis Rosset
@denisrosset
PS: happy 2017 to all!
Ben Hutchison
@benhutchison

What is the binary compatibility story of algebra anyway?

I think algebra should follow cats typelevel/cats#1233 WRT binary compat, its similarly fundamental. It can still break binary compat when needed, but such changes should be deliberate and considered, not accidental, and signalled via version numbers.

Should every dependency in a project be tied to a specific algebra release?

Ideally, no, the tying mainly happens when there are compat breaks. At minimum, libs differing on the patch version of algebra they depend upon should never be a problem.

Ben Hutchison
@benhutchison

Been looking into Algebra syntax some more. There's a problem.

What it amounts to, in my mental model, is a refactor of Spire's syntax, moving the syntax near to (ie same project as) their related typeclasses.

The problem is that those typeclasses are spread across Spire, Algebra and Cats Kernel (eg PartialOrder)
But the syntax for cats kernel isn't in Kernel, its in Cats Core (eg PartialOrder syntax). And algebra doesnt depend upon cats core, so it cannot see or use the kernel syntax
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.