I really enjoy your videos. Thanks you so much for sharing your knowledge. I've seen your videos many times but as I get closer to proficient fp I realize there are many things to practice and learn.
2021 update: In the part where I explain how the equality of State is defined, I took an approach of only verifying the output state - while this is reasonable in some cases, nowadays I would compare State values by the behavior of the entire function (S => (S, A)), with some arbitrarily-generated initial states. This would let us see more possible problems in cases where the underlying state is different and we just didn't check it in a law. Also, some of the laws in the video suffer from the problem of not really being replaceable (the issue I explained when talking about the first two laws). E.g. write(k, v) *> delete(k) *> get(k) none[V].pure[F] - this is a lie. If there was a value under `k` in the store before we ran the test, we would clear it on the left side (LHS) but not on the right side. Getting this right would also let us *not* clear the database after/before every test. There are a couple things I would do differently now, so maybe I should just publish this as another video ;)
Slap like if you noticed the mistake in the text over the worksheet... It was supposed to read: > "Anything" would be the same thing on both sides of the equation. By which I mean - it's a concrete value, but universally quantified. For all x, zero + x = x. And so on :)
I think at the time it was plain dark theme from vscode. Now I'm using a slightly modified One Dark Pro, which you can see in the latest (async/cancelable) video :)
The encoding I used is pretty much the same, but the thing about type classes is that they're supposed to be coherent (one instance per type). Algebras can have multiple valid instances, even for a single type - e.g. I can create a MonadState-based instance for IO (if I have a Ref), and a redis4cats-based one.
@@kubukoz_ So the Monoid is more an Algebra than a Typeclass ? (context : Monoid[Int] could have different zero value depending if it's a multiplication of an addition)
I missed this comment, sorry. Yeah, I think Monoid for Int is an arbitrary choice really, and you could argue that it shouldn't be a typeclass OR that it should be defined for newtypes like Add or Multiply rather than a raw Int.
I'd rather not use the word "algebra" at all, when talking about "tagless final". Using the word "agelbra" does not help to understand anything, neither for practice nor for theory of "tagless final". In my view, it's easier to understand tagless final when starting from the free monad and then passing through the Church encoding, i.e. replacing a type X by the type forall A. (X => A) => A. For type constructors, the Church encoding replaces a type F[A] by the type forall G[_]. (F ~> G) => G[A]. In fact, I'd rather say "Church encoding of the free monad" instead of "tagless final" because the words "tagless final" don't really mean much.
@@kubukoz_ Yes, I believe "tagless final" is actually the same as the Church encoding of the free monad. I will work out the full details soon in my upcoming book "The Science of Functional Programming"; I went through that in one of my video tutorials. As for "algebra", you already see a comment from a reader who is puzzled by the word "algebra" and is trying to understand what it really means. In my view, calling a function of type S[F[_]] => F[_] an "algebra" does not help anyone. In any case, thank you for your video because it's useful and important to document what we know about the design patterns that work. We can always improve the choice of words later.
Scalacheck tutorial. It looks like you have a shallow theory understanding what algebra is. Sorry but better rude truth than miseducated devs. Start with a basic cat theory (Awodey for example) and then reread Oleg's lecture note about ft.
Can you point out some mistakes I made in the explanations? It's a fair point about the understanding, I'm just repeating what I've learned in practice. Most people introducing this concept make a more obvious mistake and call every interface, parameterized with an effect type, an algebra.
@@kubukoz_ Excellent explanation, especially pointing out, without rules it is mere an interface. trait Counter[F[_]] { def incr: F[Unit] def get: F[Int] } This is a tagless final encoded algebra or tagless algebra for short: a simple interface that abstracts over the effect type using a type constructor F[_]. Do not confuse algebras with typeclasses, which in Scala, happen to share the same encoding. The difference is that typeclasses should have coherent instances, whereas tagless algebras could have many implementations, or more commonly called interpreters. This makes them a perfect fit for encoding business concepts. Ref: Practical FP in Scala, A Hands-on Approach Gabriel Volpe
I really enjoy your videos. Thanks you so much for sharing your knowledge. I've seen your videos many times but as I get closer to proficient fp I realize there are many things to practice and learn.
2021 update: In the part where I explain how the equality of State is defined, I took an approach of only verifying the output state - while this is reasonable in some cases, nowadays I would compare State values by the behavior of the entire function (S => (S, A)), with some arbitrarily-generated initial states. This would let us see more possible problems in cases where the underlying state is different and we just didn't check it in a law.
Also, some of the laws in the video suffer from the problem of not really being replaceable (the issue I explained when talking about the first two laws). E.g.
write(k, v) *> delete(k) *> get(k) none[V].pure[F] - this is a lie. If there was a value under `k` in the store before we ran the test, we would clear it on the left side (LHS) but not on the right side. Getting this right would also let us *not* clear the database after/before every test.
There are a couple things I would do differently now, so maybe I should just publish this as another video ;)
Slap like if you noticed the mistake in the text over the worksheet... It was supposed to read:
> "Anything" would be the same thing on both sides of the equation.
By which I mean - it's a concrete value, but universally quantified. For all x, zero + x = x. And so on :)
Can I ask what is the theme colour name for your ide?
I think at the time it was plain dark theme from vscode. Now I'm using a slightly modified One Dark Pro, which you can see in the latest (async/cancelable) video :)
how is an algebra different than typeclass
The encoding I used is pretty much the same, but the thing about type classes is that they're supposed to be coherent (one instance per type). Algebras can have multiple valid instances, even for a single type - e.g. I can create a MonadState-based instance for IO (if I have a Ref), and a redis4cats-based one.
@@kubukoz_ So the Monoid is more an Algebra than a Typeclass ? (context : Monoid[Int] could have different zero value depending if it's a multiplication of an addition)
I missed this comment, sorry. Yeah, I think Monoid for Int is an arbitrary choice really, and you could argue that it shouldn't be a typeclass OR that it should be defined for newtypes like Add or Multiply rather than a raw Int.
I'd rather not use the word "algebra" at all, when talking about "tagless final". Using the word "agelbra" does not help to understand anything, neither for practice nor for theory of "tagless final". In my view, it's easier to understand tagless final when starting from the free monad and then passing through the Church encoding, i.e. replacing a type X by the type forall A. (X => A) => A. For type constructors, the Church encoding replaces a type F[A] by the type forall G[_]. (F ~> G) => G[A]. In fact, I'd rather say "Church encoding of the free monad" instead of "tagless final" because the words "tagless final" don't really mean much.
We can treat it as an alias ;)
Is it really an encoding of the free monad? (honest question)
@@kubukoz_ Yes, I believe "tagless final" is actually the same as the Church encoding of the free monad. I will work out the full details soon in my upcoming book "The Science of Functional Programming"; I went through that in one of my video tutorials. As for "algebra", you already see a comment from a reader who is puzzled by the word "algebra" and is trying to understand what it really means. In my view, calling a function of type S[F[_]] => F[_] an "algebra" does not help anyone. In any case, thank you for your video because it's useful and important to document what we know about the design patterns that work. We can always improve the choice of words later.
Scalacheck tutorial.
It looks like you have a shallow theory understanding what algebra is. Sorry but better rude truth than miseducated devs.
Start with a basic cat theory (Awodey for example) and then reread Oleg's lecture note about ft.
Can you point out some mistakes I made in the explanations?
It's a fair point about the understanding, I'm just repeating what I've learned in practice. Most people introducing this concept make a more obvious mistake and call every interface, parameterized with an effect type, an algebra.
@@kubukoz_ Excellent explanation, especially pointing out, without rules it is mere an interface.
trait Counter[F[_]] {
def incr: F[Unit]
def get: F[Int]
}
This is a tagless final encoded algebra or tagless algebra for short: a simple interface that abstracts over the effect type using a type constructor F[_]. Do not confuse algebras with typeclasses, which in Scala, happen to share the same encoding.
The difference is that typeclasses should have coherent instances, whereas tagless algebras could have many implementations, or more commonly called interpreters. This makes them a perfect fit for encoding business concepts.
Ref: Practical FP in Scala, A Hands-on Approach
Gabriel Volpe