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 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 e0ccca1
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:

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
#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
#131 (comment).

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
#131 (comment).

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
#131 (comment).

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
#131 (comment).

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
#131 (comment).

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]

👍

[denisrosset]

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