Cogeninstance you can define for
FiniteDuration. But there is some history here that I didn’t quite get to the bottom of - the instance was removed in typelevel/cats#3470 and then that was reverted but I didn’t have time to dive into why
[warn] In the last 8 seconds, 7.465 (95.3%) were spent in GC. [Heap: 0.97GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using `-Xmx` or try a different collector, e.g. `-XX:+UseG1GC`, for better performance. [warn] In the last 6 seconds, 5.089 (95.0%) were spent in GC. [Heap: 0.93GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using `-Xmx` or try a different collector, e.g. `-XX:+UseG1GC`, for better performance. [warn] In the last 7 seconds, 6.254 (90.0%) were spent in GC. [Heap: 0.93GB free of 4.44GB, max 4.44GB] Consider increasing the JVM heap using `-Xmx` or try a different collector, e.g. `-XX:+UseG1GC`, for better performance.
foreachquestion is now decided on favour of the former.
Representable. If anyone wants to look at it, that would be much appreciated! :) And speaking of
Representableinstances, another obvious one would be for Product (https://hackage.haskell.org/package/base-18.104.22.168/docs/Data-Functor-Product.html#t:Product) I don’t think this type exists in Cats. Would there be interest in me adding it?
Productdoes exist as
Tuple2Kso I added a representable instance for it as well - typelevel/cats#3832
Hmmmm :thought_balloon: :thought_balloon: Given that many Scala 3 new features, like type-classes, or extension methods, or opaque types,
are to an extent driven from the lessons learned by the efforts and contortions of
cats code for Scala 2 (as well as that of other libraries) ,
perhaps we should get used to the idea of Scala 3 given different enough to merit a different coding for
Of course, dropping all ties to Scala 2 was already laborious enough... I know it is important, and hard, and urgent, and has taken over a year to get there...
After that, though, one-code-fits-both seems to lose some good features...
Another idea with Scala 3 would be to define type class methods as extension methods... typelevel/cats#3841
In essence, we would no longer need the TC and the syntax extension, only one place would give both.
Perhaps we could set up a TypeLevel community build?
Not the Scala compiler community build, but the one from cats upwards.
The community build is subsettable. you can e.g.
./run.sh -l http4s and it only builds http4s and its dependencies. there is no automation for the reverse, "please build only things that depends on cats" but
dependencies.txt has the needed information and you could extract it with a shell one-liner,
grep cats dependencies.txt and a little string munging to assemble the
./run.sh -l a,b,c command line
./narrowscript to prevent stuff you don't want from even being looked at, to speed it up
Cofree- typelevel/cats#3858. I’m pretty sure the implementation is sound but laws testing it is an interesting challenge. The issue is that sum types are not representable (as far as I know and it certainly seems intuitively obvious) and neither are trivial product types like
Const. But if we have a genuine product type
F[A]with a hole of type
Cofree[F, A]is necessarily infinite so we can’t construct an
Eqinstance for checking the laws. My only thought is that we construct an
Eqinstance that evaluates the tree to some fixed depth and asserts that the sub-trees are equal?