Add Syntax For Enumerable

[isomarcte]

Also load the existing definitions PartialNext/PartialPrevious into implicit scope.

scala> import cats.syntax.all._
import cats.syntax.all._

scala> 1.cycleNext
val res0: Int = 2

scala> 1.cycleNext.cyclePrevious
val res1: Int = 1

[satorg]

I've just realized (thanks, @isomarcte, for bringing it up) that cats.kernel.UnboundedEnumerable pretty much corresponds to cats.collections.Discrete from cats-collections. But the former is way more generic and well defined, I think. The only method the former is missing is that Discrete.adj, but it does not seem to be a big deal.

So I wonder – should we deprecate Discrete from cats-collections in favor of the existing cats typeclasses? 🤔

[armanbilge]

Yup ;)

• remove Discrete typeclass in favor of one of the cats Enumerable typeclasses cats-collections#315

[isomarcte]

Yeah, I ran into this when prototyping Interval. 😄

[satorg]

I am a bit concerned that the syntax class implements its own logic.
There's BoundedEnumerable typelclass already that implements cycleNext and cyclePrevious.
Usually the syntax should only do

Suggested change

	def cycleNext(implicit A0: PartialNext[A], A1: LowerBounded[A]): A =
	A0.partialNext(lhs).getOrElse(A1.minBound)
	def cyclePrevious(implicit A0: PartialPrevious[A], A1: UpperBounded[A]): A =
	A0.partialPrevious(lhs).getOrElse(A1.maxBound)
	def cycleNext(implicit A: BoundedEnumerable[A]): A =
	A.cycleNext(lhs)
	def cyclePrevious(implicit A: BoundedEnumerable): A =
	A.cyclePrevious(lhs)

shouldn't it?

[satorg]

...on the other hand, I think I see what you meant: BoundedEnumerable is too restrictive for that.
And I think this is because the entire hierarchy is sort of not that well-developed yet. Perhaps, there should be two more typeclasses added:

// just an arbitrary name, feel free to suggest a better one
trait CycleableNext extends PartialNext with LowerBounded {
  def cycleNext ...
}

[satorg]

Actually, there's a couple classes like that: PartialPreviousUpperBounded and PartialNextLowerBounded, but those do not seem to be well-developed either:

cats/kernel/src/main/scala-2.13+/cats/kernel/EnumerableCompat.scala

Lines 28 to 42 in bdb1ee0

	trait PartialPreviousUpperBounded[@sp A] extends PartialPrevious[A] with PartialNext[A] with UpperBounded[A] {
	/**
	* Enumerate the members in descending order.
	*/
	def membersDescending: LazyList[A] = {
	def loop(a: A): LazyList[A] =
	partialPrevious(a) match {
	case Some(aa) => aa #:: loop(aa)
	case _ => LazyList.empty
	}
	maxBound #:: loop(maxBound)
	}
	}

I wonder, why does it inherit to PartialNext if it does not use anything from the latter?

[isomarcte]

@satorg Yeah, there are some issues here.

So, first off, RE the syntax classes having logic. I don't want to demand a constraint of BoundedEnumerable because someone might define a PartialNext and LowerBounded as separate definitions and then we won't be able to solve for the instance, e.g. like Decoder Encoder in circe or Get Put in Doobie.

Secondly, I think there is a more complete and less restrictive encoding for what PartialPreviousUpperBounded and PartialNextLowerBouneded are trying to do. I'm prototyping it out here: isomarcte@9debe1c#diff-805a1fb053663f9d27cfcb8586bc2310cbe9a649366549b8d0106a366774e2e3R45

Keep in mind, that is a rough early draft of what I'm calling Countable (should probably just be called Enumerable). It can be defined for both finite and infinite types, unlike PartialPreviousUpperBounded.

I'm trying to work out how the whole hierarchy should look.

The cycleNext and cyclePrevious functions are interesting. Technically, we could define these for unbounded (infinite) types as well, they would just be aliases for next and previous. That is to say, the cycle over an infinite domain, is just a cycle which never wraps. This might be nice if someone wanted to endlessly enumerate over a domain, not caring if they were cycling or just going on forever. 🤷

Countable (or Enumerable) would be really helpful for defining an Interval type. The stdlib Range and cats-collection Range is sort of trying to be both a convenient way to enumerate a series of elements and also a true mathematical interval, with the stdlib version leaning a bit more into the former and cats-collection's version the latter. I think that is why we have some ergonomic issues with those types. However if we define Countable separately then we can solve the "I want to enumerate over some set of values problem" and having that as a constraint also makes writing Interval a lot nicer. Specifically, saying that an Interval is something that maps to the natural numbers opens up a whole lot of optimizations and ergonomic benefits.

Sorry, I got a little off topic there. All that Countable stuff would be another PR once I've sorted out how I think it might all fit together with the existing classes. For now, I just wanted to get the syntax in place for what is already defined, with minimal constraints.

[satorg]

I appreciate you deep involvements into the topic. Actually, I think you already have a suggestion on how the concern could be solved, don't you?

cats/kernel/src/main/scala/cats/kernel/Enumerable.scala

Lines 256 to 257 in be74ffc

	def nextOrMin(a: A)(implicit A: LowerBounded[A]): A =
	partialNext(a).getOrElse(A.minBound)