Would it be rational to introduce a Typelevel Rational?

[benhutchison]

Rational numbers are widely useful to represent fractional quantities.

Within Typelevel, there are implementations in Coulomb and Spire. There are probably other users who are rolling their own, or using other java libs, or using possibly inferior techniques like lossy Doubles as a fractional rep.

Both Coulomb and Spire are IMHO too heavy and complex to serve as a shareable substrate if one just wants a Rational number. Perhaps that's a factor in why Coulomb didn't rely upon Spire?

Extracting a common, highly focussed Rational micro-lib might be a .. rational course of action?

[erikerlandson]

I looked into this idea over on singleton-ops:
fthomas/singleton-ops#140

It turned out there were some technical issues there, and it never quite gelled.

One typelevel design perspective I have evolved over time is that making explicit types for things can actually bite you. If you qualify your type parameters, for instance something like:

type Rational[N: Int, D: Int]
type Power[V, E: Rational[_: Int, _: Int]]

You rapidly find that these type qualifiers metastatize through your type parameter declarations, and it becomes quite hard to satisfy the compiler. The alternative is to simply use unqualified types, and then you write your implicit rules, or macros, to recognize certain patterns and support them. This has the added advantage of allowing you to add new supported patterns if you think of them.

There is one slight disadvantage. The compiler will still give you compile-time type errors when you want them (unrecognized pattern), BUT... the nature of the error may or may not make it obvious what the exact problem was. That's a tradeoff I'm personally happy to make, but it is a tradeoff.

An example of this kind of "unqualified pattern matching":
https://github.com/erikerlandson/coulomb/blob/scala3/core/src/main/scala/coulomb/infra/meta.scala#L56

(this is in macro space, however the same kind of matching rules can be implemented directly in implicit declarations, which I did more extensively in the old scala 2 code)