General topics relating to the the Typelevel project http://typelevel.org/ | See also individual project channels | Code of conduct https://www.scala-lang.org/conduct/
rossabaker on bundler
rossabaker on development
Bump nokogiri from 1.13.4 to 1.… Update gemset Merge pull request #340 from ty… (compare)
rossabaker on bundler
Update gemset (compare)
dependabot[bot] on bundler
Bump nokogiri from 1.13.4 to 1.… (compare)
rossabaker on development
Update outwatch data Merge pull request #339 from co… (compare)
rossabaker on development
Fix broken links on call-for-st… Merge pull request #338 from ty… (compare)
rossabaker on broken-links
Fix broken links on call-for-st… (compare)
rossabaker on broken-links
Fix broken links on call-for-st… (compare)
rossabaker on update-flake
Update flake (compare)
rossabaker on bundler
but in abstract F you'd run into a fact that now you need to propagate that damn new constraint quite a lot
eventually I'm going to start playing with some sort of Free structure again and have the best of both worlds. Just have to figure out how to make composition not suck :P (but the thing is, defining something like fs2 or Resource will still need tagless)
- Effect polymorphism
It is now the caller of combineStuff who decides what the effect type will be, not the definition of combineStuff itself. combineStuff may be called with IO arguments, or Future or Option or indeed any Monad. Our method can handle them all, without having to care what their concrete type is.- Error-reduction
The possible implementations of combineStuff is severely restricted because the types of the arguments are abstract: we only know that e1 and e2 are of type F, and the only methods we can invoke are those provided by the Monad[F] typeclass instance. This reduces the possibilities of errors, because we can’t do anything except what the constraints (typeclass instances) allow. There is literally less that can go wrong.
@neko-kai: thanks for the link, will explore it 👍 I'm basically interested in Scala 3, as that's the future, although I wouldn't like something that can break in future versions.
I'm also thinking that I could just rely on Scala 3 giving proper import hints. I noticed that it does that, but I have no idea how reliable it is.
cd
into it and run sbt
from there.)
IO[Assertion]
or something like that? I'd check the cats-effect-testing, I know it has specs2 integration
cats-effect-testing-spec2
works fine, but if I use the conversions it provides for specs2 inside one of the specs2's prop
block, then each property run gets executed synchronously. On the other hand scalacheck-effect
allows to compose all property runs into a single IO
(of any other F
) and execute the unsafe sync run only once for all property runs.
scalacheck-effect
and specs2