Magma and a property as trait based approach.

[johnynek]

So looking at our table in the readme, you might notice that all structures are associative. We could say that a Semigroup is an associative Magma:

trait Magma[T] {
  // no law here other than closure, which the type-system guarantees.
  def combine(a: T, b: T): T
}

If we had this, then on binary operations we could just have some traits like:

trait Associative[T] extends Magma[T]
trait Commutative[T] extends Magma[T]
trait Idempotent[T] extends Magma[T]

We can keep the named entities, but it would be nice to have a method like:

object Semilattice {
  def from[T](t: Idempotent[T] with Commutative[T] with Associative[T]): Semilattice[T] = ...
}

object Band {
  def from[T](t: Idempotent[T] with Associative[T]): Band[T] = ...
}

Just a thought. Then the situation we got into with Ring is clearer too: we have traits for all properties that extend some root type: RingLike[T] or something that has plus and times. Then we have a bunch of traits for that table. We still name the common ones, but it is clear how to express any set of properties, even if we don't have a formal name for that type. And it easy to get an instance of named type by satisfying the properties.

[non]

I think this is really compelling. One question: should we require type classes to be "mixed"? E.g. should we talk about [A](implicit ev: Idempotent[A] with Commutative[A] with ...) or should we talk about [A: Idempotent: Commutative: ...]?

This came up in previous discussions in Spire, and it seemed like requiring something like EuclideanRing[A] with Eq[A] (for example) was too restrictive, since it makes it harder for someone to use a custom (or non-standard) instance with a standard one. In this case maybe it's different, since things like Associative[A] are inherently bound up with Magma[A] and it's clear that you'd need to define your own type class if there isn't one already available.

But overall I think this is a really nice idea, and it does seem to generalize the place that our approach is moving toward. What do you think @tixxit and @avibryant?

[non]

I think whatever we decide this is the kind of decision that would go well for a style/design guide, explaining how we expect folks to use and extend algebra.