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
in scala 3
Daniel Spiewak
tagless final has many issues, particularly in Scala, but this is one area where it's very very good :-)
Fabio Labella
in scala 2 I have to say usability can be poor, for orthogonal reasons
Daniel Spiewak
though it's not as bad as it could be
Fabio Labella
for example that writing implicit arguments lists is too verbose, but context bounds have ton of know how
it's pretty good once you know
but the ramp up experience isn't great
Daniel Spiewak
Ashkan Kh. Nazary
Then its the right track, only more experience required and some improvements on the language
Fabio Labella
in scala 3, with using and given at the call site
beginners will have a much easier time
and it looks pretty enough
Daniel Spiewak

Then its the right track, only more experience required and some improvements on the language

in my obviously-unbiased (:kappa:) opinion, yes :-)

it also would help to have better examples and better guidelines and higher level tooling layered on top of hte primitives
CE3 opens the door to a lot of that tbh
because then the foundation is much more composable and we can build really awesome high level stuff
Ashkan Kh. Nazary
Can you guys give some canonical examples where tagless final is the wrong choice ? I've read a lot of material on it but so far to me it feels like this is the more powerful and expressive encoding (it solves the expression-problem , what can be wrong with it ?)
Fabio Labella
I'll tell you
it's not a great choice as the implementation of advanced monads
IO and Stream are written essentially as Free monads
Daniel Spiewak
(oh I see what you're getting at; agreed)
Fabio Labella
so the "returning descriptions out" rather than passing behaviours in
Daniel Spiewak
that's not a frequent userspace constraint though
Fabio Labella
also, there are different ways of doing final tagless
final tagless just means representing your language as functions whose result is a type parameter
trait Foo[F[_]] {
  def foo[A]: F[A]
for example
but then, how you pass that around can vary
I distinguish between at least 3
the ML way, the haskell way, and my way (lol, the algebraic effects way)
the ML way is quite OO as well, actually
basically you pass those things explicitly, using classes to group things
ML as in Standard ML the language, cause it's somewhat reminiscent of modules there
or alternatively, reminiscent of OO and dependency injection
which tbh is a much more familiar metaphor
case class Thing[F[_]](t: Foo[F])  {
   def yourMethod
it's the simplest way, and works well even if you don't do final tagless, and stick to concrete IO
the second way is the haskell way, so true typeclasses
Daniel Spiewak
(I do this one tbh)
Fabio Labella
meaning that instances are unique
Ryan Peters
^ I was just going to say, I've just passed dependencies around as explicit parameters, not using implicits. I'm not entirely sure why this gets overlooked in the discussion. I blame a certain presentation for giving people the idea that TF requires you pass things around with implicits, since it focused on that a lot in its examples.
Fabio Labella
so if your algebra has a requirement for a runtime thing, such as Config, or a Ref, it's going to be an instance over Kleisli
this is the traditional way of doing things, but imho the worse as well
this is where "transformers are scary" meme comes from
the third way is what I like to call implicit call sites
and it's close to how you do things with algebraic effects
but basically pass things implicitly, but with no implicit instances available by default
you only make them available at the call site
right before using them
which your traits can have state, be created in Resource, etc