Names of operations of for semigroups, monoids, groups

[denisrosset]

In algebra, the name of the associative operation is combine, the identity is empty, the identity test is isEmpty, while in spire, it is op, id and isId.

The combine/empty terminology is appropriate when concatenating data structures, while op/id is standard abstract algebra.

The change came from non/algebra@e0ccca1 (thanks @rklaehn for finding it), and the compromise came probably from usage in cats --- but I was unable to find the discussion leading to the commit.

When basing spire on the algebra typeclasses, this notation is going to impact especially the people using Group in an algebraic setting.

What should be done?

I see two options:

1. standardizing on one set of terminology, and have syntax adapters in client libraries to provide the missing names (e.g. in spire or cats, depending on the context)
2. having both terminologies in the typeclass

[johnynek]

In fact algebra considerably predates cats. Algebra started as a project for a common core to spire and algebird.

In algebird we made the choice of Ring extending Group, and made the choice to just call the semigroup operation plus (yes it is sometimes weird, but the most common instances make sense and being less abstract there I believe helped adoption within Twitter).

For algebird I had planned (but not thought too deeply) about making algebird Semigroup have final combine that calls plus. Thus if you subclass an algebird Semigroup your code does not change but it works as an algebra Semigroup.

Having adapters is another approach but it makes it less convenient when it is time to interop, but he upside there is that you could put them in a separate package and those that don't want them don't have to have the dependency (I'm paranoid about dependencies from the trauma of working in a monorepo).

On Wed, Dec 9, 2015 at 05:49 Denis Rosset notifications@github.com wrote:

In algebra, the name of the associative operation is combine, the identity is empty, the identity test is isEmpty, while in spire, it is op, id and isId.

The combine/empty terminology is appropriate when concatenating data structures, while op/id is standard abstract algebra.

The change came from non/algebra@e0ccca1 https://github.com/non/algebra/commit/e0ccca1 (thanks @rklaehn https://github.com/rklaehn for finding it), and the compromise came probably from usage in cats --- but I was unable to find the discussion leading to the commit.

When basing spire on the algebra typeclasses, this notation is going to impact especially the people using Group in an algebraic setting.

What should be done?

I see two options:

1.

standardizing on one set of terminology, and have syntax adapters in client libraries to provide the missing names (e.g. in spire or cats, depending on the context) 2.

having both terminologies in the typeclass

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131.

[denisrosset]

Thanks, I did not see the empty / combine methods in algebird.

[johnynek]

They have not been added. I think empty/combine actually came from scalaz back we we had planned to use these classes there as well.

But my current (not well thought out) plan is to add the methods.

On Wednesday, December 9, 2015, Denis Rosset notifications@github.com wrote:

Thanks, I did not see the empty / combine methods in algebird.

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131#issuecomment-163318705.

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[TomasMikula]

I think empty/combine actually came from scalaz

Scalaz calls them zero/append, at least as of today.

[johnynek]

Okay, I found the discussion. It was an email thread with Avi, Erik, Lars, Tom and I and we proposed a bunch of different possibilities. Avi actually proposed combine on 2013/10/20 and we felt like that was the best compromise by 10/22.

On Wed, Dec 9, 2015 at 8:25 AM, Tomas Mikula notifications@github.com wrote:

I think empty/combine actually came from scalaz

Scalaz calls them zero https://github.com/scalaz/scalaz/blob/e78f50de3ef6df84aa8a4ff21d023677f3e39dd1/core/src/main/scala/scalaz/Monoid.scala#L23 /append https://github.com/scalaz/scalaz/blob/e78f50de3ef6df84aa8a4ff21d023677f3e39dd1/core/src/main/scala/scalaz/Semigroup.scala#L22, at least as of today.

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131#issuecomment-163349175.

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[denisrosset]

I'm OK with combine, it's not so different than op to describe a binary operation; and in Spire, it is most often written using the symbolic operator |+|.

I'm less happy with empty, which has additional meaning compared to id or identity --- in that sense, id(entity) is more generic.

All the monoid tutorials declare that the empty string "" is the identity when concatening (even our own README here).

But to write g.isEmpty to check whether a group element is the identity seems weird; when reading mathematical code, one easily concludes that g is a container or a collection.

(Still, I don't want to revive a negotiation that already happen between the algebird and spire maintainers.)

[johnynek]

Well id is more often used in programming to be a short form of an identifier (e.g. user.id).

identity is confused with the scala Predef.identity.

There were no perfect choices, it seemed to us.

On Thu, Dec 10, 2015 at 2:43 AM, Denis Rosset notifications@github.com wrote:

I'm OK with combine, it's not so different than op to describe a binary operation; and in Spire, it is most often written using the symbolic operator |+|.

I'm less happy with empty, which has additional meaning compared to id or identity --- in that sense, id(entity) is more generic.

All the monoid tutorials declare that the empty string "" is the identity when concatening (even our own README here).

But to write g.isEmpty to check whether a group element is the identity seems weird; when reading mathematical code, one easily concludes that g is a container or a collection.

(Still, I don't want to revive a negotiation that already happen between the algebird and spire maintainers.)

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131#issuecomment-163599119.

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[TomasMikula]

I don't mean to revive the negotiation either (I really don't dwell on names), but was neutral in consideration?

[johnynek]

It was not. ident was, but not too deeply.

Honestly, we didn't bikeshed it too much. We had three libraries:

scalaz: zero, append spire: id, op algebird: zero, plus

Spire folks didn't like zero so much. I didn't like "id" so much. neutral is pretty good, if you ask me. That said, since spire has already adopted these names in master and cats also uses it, I am dubious that the migration cost at this stage is worth it.

On Thu, Dec 10, 2015 at 8:18 AM, Tomas Mikula notifications@github.com wrote:

I don't mean to revive the negotiation either (I really don't dwell on names), but was neutral in consideration?

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131#issuecomment-163707731.

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[denisrosset]

Not yet for Spire, it is still "id" in master. There is a PR in discussion for the merge with algebra, where "id" is going to be migrated to whatever algebra provides.

I like very much "neutral", and the name is already used in a few algebra textbooks for a group "identity".

(I don't know the status of "cats", and if they would agree on "neutral").

Still, I'd like a project named "algebra" to use names not too far away from the mathematical standards. In that view, "empty", "isEmpty" are quite misleading--- it is even worse with partial groups that have left and right identity elements, which would be named "leftEmpty", "rightEmpty", while "leftNeutral" is pretty straigtforward.

[johnynek]

Well now is the time to propose this. We are very near a release that we hope can be binary compatible, at least for core, for some time.

If you feel passionate about this, I'd recommend discussing it in the cats gitter channel as well.

I hear you, and I like neutral better, but working in large code bases I am willing to make compromises for interface stability. A name change can be thought of as an externality: it is pretty cheap for an OSS project, but all the consumers pay the price. Working in a large monorepo where the library author pays the price for changes has made me more sensitive to this fact.

On Fri, Dec 11, 2015 at 12:29 AM, Denis Rosset notifications@github.com wrote:

Not yet for Spire, it is still "id" in master. There is a PR in discussion for the merge with algebra, where "id" is going to be migrated to whatever algebra provides.

I like very much "neutral", and the name is already used in a few algebra textbooks for a group "identity".

(I don't know the status of "cats", and if they would agree on "neutral").

Still, I'd like a project named "algebra" to use names not too far away from the mathematical standards. In that view, "empty", "isEmpty" are quite misleading--- it is even worse with partial groups that have left and right identity elements, which would be named "leftEmpty", "rightEmpty", while "leftNeutral" is pretty straigtforward.

— Reply to this email directly or view it on GitHub https://github.com/non/algebra/issues/131#issuecomment-163903929.

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[denisrosset]

@johnynek Great that it's not too late! I should have been watching non/algebra more closely.

I'm very much in favor of non/algebra not breaking binary compatibility, and avoiding fragmentation in client libraries.

I'm now looking to the other typeclasses to see if I spot something unusual - coming from an abstract algebra viewpoint.

(I just completed a PhD in physics, so my background is more on the theoretical physics/abstract algebra side).

[rklaehn]

For the record: I prefer neutral over empty as well. As somebody without a math background, neutral seems very descriptive.

I can not really estimate how many people would be affected by this change. Since neither algebird nor spire are using algebra atm, the biggest impact would be on cats.

[johnynek]

@non thoughts? I expect you understand Cats better.

[denisrosset]

The feedback I got from cats' gitter is positive, I will propose a PR for the name change.

[johnynek]

sounds good.

[denisrosset]

Renaming done in referenced PR.

[rklaehn]

:+1:

[denisrosset]

That's an old issue, we went a different route. Going to put aliases in my group theory code.