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/
code written in concrete
IO by people that know how to write tagless final code is probably just as nicely separated
but it's another layer of discipline which is nice to avoid if you can
the problem i have with the discipline argument is that folks can equally use it to justify no IO at all
which at least for me stops and makes me write the code purely cause it's equally painful anyway
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)
my answers are like rob's (from my book):
- 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.
How do nontrivial scala projects tend to maintain sample projects? (In Slick there's a lot of code in the SBT build dealing with it, which I'd like to simplify or eliminate, and I'm trying to find out what other people do.) For instance, do sample projects each get their own repo or are they subdirectories in the same repo? If the latter, are they part of the main SBT build, do they have their own SBT build, or both? In any case do you automate keeping them up to date, and if so, how?
That is, you could copy the subdirectory to a new project with that being the base directory. (Or, you can
cd into it and run sbt from there.)
But somehow that requires a bunch of complexity
I guess a lot of projects have giter8 repos... how do they keep those up to date?
In a way it seems more logical to make sample projects standalone projects, after all that's what they represent, but then as you said how do you keep it from going stale
Then again nowadays we have Scala Steward
I think some library maintainers didn't even think about that — it's a fairly subtle point and not a super well-known one. Also, the farther you are from the root of the ecosystem, the harder it can be to maintain that policy without having to complicate your build with version conditionals. At some point it's pretty tempting to just throw up your hands.
A lot of libraries didn't drop RC3 when publishing for 3.0 — so the news on this wasn't all bad.
I work on library code so all my examples are really just "how to use feature X" or "how to work around bug Y" as opposed to standalone things that you might want to use a starting point for a project.
You might see what the current story is re: scala-steward + g8. It's possible that ss will keep stuff up to date in g8 projects now. It's been a few years since I looked.
@SethTisue I don't think I've ever cross-published anything for multiple language pre-releases, and given that the Scala 3 release process for Circe is still manual, I wasn't inclined to start now. Expecting adopters to coordinate updates seems completely reasonable to me (unless they want to pay for not having to do that).
@djspiewak I believe lampepfl/dotty#12660 might fix the weird issues you saw trying to use the scala 2 version of cats-mtl from scala 3 (huge props to @kubukoz:matrix.org for the minimization!)
What part? Is it that you need to have your tests returning
IO[Assertion] or something like that? I'd check the cats-effect-testing, I know it has specs2 integration
@daenyth:matrix.org indeed,
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.
But seems there's no out-of-the-box integration between
scalacheck-effect and specs2