Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Fabio Labella
I love types, and in the right amount, they tremendously help with modelling
however, when using them to encode correctness, it's easy to hit diminishing returns
for example
findUser returns User
authenticate also returns User
so types aren't helping distinguish an authenticated from a non authenticated User
so if you want to "type to the max", you might introduce a AuthedUser
but then you realise a bunch of functions need to work with both types of users
so you introduce a phantom type User[A <: AuthStatus]
so that you can check at compile time
oh, but now lots of ops become typeclasses
and then you realise you aren't tracking Banned at the type level!
and so on
codebases that do this are among the most brittle and fiddly to work with among the things that I've seen
and then eventually you hit a case where you need dependent types (real ones), and the whole castle crumbles
so, type safety definitely doesn't have the same tradeoff profile of, say, referential transparency
being 100% referentially transparent with IO is the correct choice for a lot of code
being 100% type safe is often counterproductive instead
someone really needs to publish a book of your gitter storms Fabio
Fabio Labella
I thought about a book a few times tbh
but it fits into those "philosophy of CS" stuff which is hard to justify
👍️ really good insight indeed. A lot to think about and play with :)
Brian P. Holt
I have a function A => Resource[F, B] but I don’t have a value for A yet. Can I transform that into Resource[F, A => B]?
Gut feeling: no
I think if you squint, that's actually a traverse
between Resource and Reader
and Resource isn't traversable
though.. maybe I'm wrong?
Actually, I think it's this: You can do it when F is traversable
because it's almost the same thing as having A => F[B] and wanting A => B
(IO etc are not traversable)
Brian P. Holt
haha well I’m glad I’m not the only one who thought it looked familiar but not immediately obvious
with less squinting: in the first example, the allocation of the resource can make use of the A - in the second, it can't.
Fabio Labella
your question is equivalent to saying: can I get a monad out of an applicative? and the question is you can't
monad, applicative and functor can all be seen as producing an F[A] => F[B] starting from different arrows
map: (A => B) => (F[A] => F[B])
ap: F[A => B] => (F[A] => F[B])
flatMap: (A => F[B]) => (F[A] => F[B])
A => F[B] is the essence of being monadic, i.e. context sensitivity, I can use the result of a computation to decide the shape of the next
this is what A => F[B] says: => means "depends on", so F depends on A (the next computation depends on the result)
in F[A => B], A cannot decide F, since it doesn't even see it (it's on the outside, in F[A => B])

in F[A => B], A cannot decide F


That's a very clear way to lay that out
teo danciu

your question is equivalent to saying: can I get a monad out of an applicative

Sorry, just curious, going from A => Resource[F, B] to Resource[F, A => B] - how come it's not "can i get an applicative out of a monad" , based on the definitions above?

Fabio Labella

Hey Teo :)

Applicative lets you work with F[A => B], so if you could transform A => F[B] into F[A => B], that would mean that monadic operations could be expressed with applicative operations, i.e. that given an applicative, you could get all that monad can do

Jozef Koval
Hi guys, I am struggling a bit with following signature: f: List[Resource[F, A]] => Resource[F, List[A]] I wanted to use traverse but could not make it compile. Do you think it is even possible?
Fabio Labella
.sequence should do just fine there (or traverse(x => x))
let me know if you still can't make it compile
Jozef Koval
do I need some special imports? currently I only have import cats.implicits._ but I get error:
polymorphic expression cannot be instantiated to expected type;
 found   : [G[_], B]G[List[B]]
 required: cats.effect.Resource[F,List[Foo]]
Fabio Labella
what scala version are you on?