Should we remove the construction methods in algebra.lattice?

[johnynek]

In the lattices, we have a number of methods to create ring structures from lattices. These seem like particular constructions to me, and perhaps not best bolted onto the traits themselves.

For instance, we could add:

trait Semigroup[T] {
  //...
  def asMonoid: Monoid[Option[T]]
}

which is a construction to create a Monoid from a semigroup using None as the unit, but I wouldn't want to do that. Similarly we can build a Ring[(BigInt, T)] from a Rng[T] by adding a 1 element and counting how many times it has been added (a: BigInt, t: T) = a * 1 + t, but again, that construction I would rather have a named class for that than bolt it onto the trait.

By contrast, .meetSemilattice is not a construction, it is exactly taking the meet and returning a Semilattice instance which combine == meet. This feels different to me.

Somewhat similarly is the .dual. Maybe we should have case class DualLattice[T](lattice: Lattice[A]) extends Lattice[A] or some such, instead of methods on the traits.

[TomasMikula]

Note that the return type of dual is overridden in more specific lattices, so one DualLattice class will not cover them all.

[johnynek]

Yeah. dual we can either set aside from this discussion, or make DualX for each X. I can't see another way to do that.

[non]

I would be fine removing these things. It may be the case that we will want to use something more like Dual[Bool, A] to do something like this.

[non]

Given all the confusion around these methods (what to call them, what their return types should be, whether they will be refined in subtypes, etc.) I think we should just remove them and handle this via a different mechanism.

[TomasMikula]

Yeah, it makes more and more sense to me :+1: