Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Fabio Labella
@SystemFw
but one example would be the intuition that *> means "and then"

State , check
IO, check

Ok the intuition holds...

List(1,2,3) *> List(4, 5, 6) <--- intuition breaks
again, fs2.Stream behaves like List in many respects so this is a good exercise regardless
felher
@felher
Oh, that's a great example!
Fabio Labella
@SystemFw
the instances for (-> a) (Reader) are also useful for breaking wrong intuitions / expanding one's mind, but they work better in Haskell
Emily Pillmore
@emilypi
@SystemFw when the Lambdaconf vids come out, look for it. I don’t think he’s posted slides, but you could ask him
it was effectively managing logging states using reader + pprism and plens
as opposed to the usual StateT-type solution
Fabio Labella
@SystemFw

Most literature focuses on implementing them on one hand, or in "real world examples" without much explanations on the other, whereas I think developing the sort of thinking that lets you write code using algebras only is very important, and not necessarily always explained well

@felher this really matters to me so I want to expand a bit. Let's take State as an example. In most cases books/tutorial fall in two categories:

  • "let's develop a web server where each request has a request context, to do this we can use State from cats, which has amodify function that we can use in a for comprehension. Don't worry about how it works now...[proceeds with concrete example]"
  • "Abstracting over state can be done with a => (a, s) where each function gets a new copy of the State. If we write down a couple of example we can see that it fits the Monad abstraction. Let's write the instance for Monad"

Obviously they are both useful in different respects, however there are drawbacks:

  • The first approach is good to break the ice/show you that you can write real code in FP, but it doesn't give a lasting understanding imho. You need to understand the foundations.
  • The second is good at explaining State, but it doesn't necessarily give you transferable skills that you can use with other abstractions for which you don't know the internal representation. A typical example where this breaks is when introducing IO.

I like to use a third approach. After having explained what the main algebras bring to the table (Functor lifts 1-arg functions, Applicative lifts n-ary functions, Monad gives you context sensitivity), I present State like this:

State is a datatype representing computations that describe modifications to a value, with the following algebra:

trait State[S, A] // S state, A output
object State {
   def get[S]: State[S, S]
   def set[S](s: S): State[S, Unit]

   implicit def m: Monad[State[S, ?]] // stress that this implies Functor and Applicative
}

and then you have them write programs in this "language", without knowing anything about the internal representation, but only the State algebra (get, set, what the type means, any laws, the monad instance). After they manage to use it like that, you can explain how it's implemented (typically you'll go back and forth a few times in real life). The advantage is that this is aimed to instill the sort of algebraic thinking that is not only one of the biggest advantages of FP, but also necessary when you deal with opaque/complex abstractions like IO or Stream

@emilypi right, the thing with local, I'm been waiting for the talk for a while. That's still ReaderT though I think?
I actually also have a pretty cool use of Reader, but it's advanced so I didn't mention it here
felher
@felher
@SystemFw thanks, this is very good advice.
Emily Pillmore
@emilypi
@SystemFw yeah, basically. I believe it was readert yeah. Very cool stuff
Reader is underrated
So is ReaderT
felher
@felher
@SystemFw I think I will introduce Reader in the way you said. Since reader has only additional operation, ask, I think this is a good place to start.
Fabio Labella
@SystemFw
yeah, that's true
not a lot you can do with Reader alone though
felher
@felher
True. I don't think it's too much of a problem, though. The students will be happy if there is something they can grasp completely and where they have a glue as to how the exam at the end of the semester might look like.
Fabio Labella
@SystemFw
ah, this is in a properly academic setting
fair enough, I've only taught in industry :)
Christopher Davenport
@ChristopherDavenport
Exam Season - PagerDuty
Atleast that’s how I see it. If I have no bugs, I sleep soundly.
Emily Pillmore
@emilypi
In Haskell at least, I find myself using it implicitly often
Less so consciously, more arrows in general
Fabio Labella
@SystemFw
@emilypi I'm not talking in general, just about the fairly specific example of teaching algebras like above. With State only you can have them write quite a few interesting programs, with Reader less so (unless you have ReaderT). Btw my favourite non-obvious use case is using Reader to write shapeless typeclass instances that depend on a runtime value
Emily Pillmore
@emilypi
Ah yeah
Taleb Zeghmi
@talebzeghmi

Hi,
Playing with introduction code http://47deg.github.io/fetch/docs.html#introduction-0

// type Fetch[A] = cats.free.Free[fetch.FetchOp, A] 
def getUser(id: UserId): Fetch[User] = Fetch(id)

for {
  x: User <- getUser(1)
} yield s"${x.id} ${x.username}”

Produces following error:
Error:(105, 23) value filter is not a member of fetch.Fetch[User]

Thoughts on how to get around this?

Taleb Zeghmi
@talebzeghmi
Why is it trying to call withFilter?
Emily Pillmore
@emilypi
because for comprehensions are implemented poorly.
every time you have a predicate on your type like : Type or if foo, it calls withFilter
Oleg Pyzhcov
@oleg-py
or a pattern like (a, _) <- something
basically at the left hand side to the arrow, anything but a simple name is a withFilter call
Emily Pillmore
@emilypi
you can get around this usually by defining the syntax for your type and writing the withFilter :: MonadError f e => (a -> Bool) -> f a -> f a function yourself, but honestly you should probably just have @oleg-py’s better for on all the time anyway (along with kind projectors or pascal)
Taleb Zeghmi
@talebzeghmi
it seems that’s forcing me to switch from Gradle to sbt, or have to exclude : Type in for comprehensions...
Emily Pillmore
@emilypi
well, if you type your functions appropriately, most of the time you don’t need the type annotation
Taleb Zeghmi
@talebzeghmi
@oleg-py thank you!
Rob Norris
@tpolecat
@felher @SystemFw I think Reader is at least a little bit interesting because it gives you dependency injection. When you’re first learning it’s eye-opening I think. I was impressed anyway.
I also found State’s implementation to be very eye-opening because dispelling the magic is important. That was really the one that tipped the scale for me.
Fabio Labella
@SystemFw

also found State’s implementation to be very eye-opening

Oh yeah, I'm not saying you shouldn't explain it. I'm saying that if you start with the algebra only you can also gain some more transferrable skills which are essential but never taught. After that, you can explain how State works internally

Rob Norris
@tpolecat
:+1:
felher
@felher
@tpolecat Yeah, Reader I will definitively go through. Dependency inejction with it is cool, and is the obvious use case I will explain. I think the real power comes with ReaderT. But you have to start somewhere and monad transformers are out of reach at the moment.
Fabio Labella
@SystemFw
@felher are you using scala or haskell?
for the course I mean
felher
@felher
I also think I will do Writer, and now probably List in a bit more detail since @SystemFw has suggested that.
@SystemFw The course is in Scala. Recommended reading is the red book.
Fabio Labella
@SystemFw
Nice, then I have another small exercise