Aha! So there is one for normal form! I wondered about that :D But now I wonder, why do you have to define NFData for _everything in reality?_ Is there a good reason for that or is it just that DeepSeq is not a platform primitive, but simply defined in terms of seq and defining any system-wide-implemented recursive function through pattern matching will cleverly create a "deepseq" out of just "seq"? ;3 It seems a pain to have to define implementations of it though. What if you use a library and need to call deepseq in one single place..but the library didn't happen to define instances of NFData for all its types and there are dozens of types. Do you have to define instances of it for dozens of types? X_X (Also this seems very rote and monotonous and so perfect for a "deriving" template-thing :3 ) Is there a case where you _don't_ want NFData to work normally like the example you gave with chaining rnf and seq?
The problem is that there are cases where an implementation of NFData is simply impossible or ambiguous! data A = A A How would we define an instance of NFData for this type? Any reduction to normal form of the A type would simply result in non-termination, so there is no real point in defining rnf for this datatype. It does not have a normal form that we can practically use. Another problem are references used in monadic contexts. Would rnf evaluate the reference or the referenced value? (The standard implementations for IORef and STRef are only strict in the reference NOT in the value!). This ambiguity makes deriving the NFData instances impossible! If you want to create your own reference types you might want to avoid this confusion alltogether and simply not implement NFData and forbid strictness. It's true that, when using some library that does not implement the NFData instances, you need to do it yourself (I atleast don't know of any automatic ways to do it). Sometimes, lazy evaluation forces us to not be lazy after all. :P
@@philipphagenlocher Ahhh so it's like Eq or Ord in that it seems like there should be an obvious one right way to do it, but in reality there could be multiple or no sensible ways for unusual things; thanks! :> (Still though, there's a simple field-by-field 'deriving' default implementation for Eq and Show and Read and etc. that we just accept only works for like 90% of cases or something, and you have to manually write it when it doesn't. It seems like NFData could have that as an option too. But on the other hand, idk maybe the set of standard typeclasses for "deriving" was fixed before NFData was standard so it wouldn't have mattered?)
Do you have a video on semigroups/monoids? I can't find much out there that clearly explains what they are - I've flicked through your playlist briefly but cant see anything :(
They are planned! The roadmap for the next few videos looks like this: Parallelism -> Profiling -> Category Theory (which will probably span multiple videos talking about semigroups, monoids, functors, applicatives and monads again) -> Lambda Calculus -> Formal Proofs
Recently I watch the Tsoding video about creating music with Haskell th-cam.com/video/FYTZkE5BZ-0/w-d-xo.html This is a /kinda/ real application, and it presents a way to create music (wave files) from scratch. I suppose this format could be used from time to time to present real-life examples of the different notions you teach, in a fun and practical way.
Best Haskell tutorials on TH-cam so far! Thank you
This show just keeps gettin better!
A tip: you can watch movies at kaldrostream. Been using it for watching all kinds of movies recently.
@Chad Elliot definitely, I've been watching on Flixzone} for years myself :)
I saw all your videos so far, in a single day. Please, keep up the good work!
Great content again!
Great video series.
Was there a conscious choice not to use function composition?
great video...
Excelente :)
Aha! So there is one for normal form! I wondered about that :D
But now I wonder, why do you have to define NFData for _everything in reality?_
Is there a good reason for that or is it just that DeepSeq is not a platform primitive, but simply defined in terms of seq and defining any system-wide-implemented recursive function through pattern matching will cleverly create a "deepseq" out of just "seq"? ;3
It seems a pain to have to define implementations of it though. What if you use a library and need to call deepseq in one single place..but the library didn't happen to define instances of NFData for all its types and there are dozens of types. Do you have to define instances of it for dozens of types? X_X
(Also this seems very rote and monotonous and so perfect for a "deriving" template-thing :3 )
Is there a case where you _don't_ want NFData to work normally like the example you gave with chaining rnf and seq?
The problem is that there are cases where an implementation of NFData is simply impossible or ambiguous!
data A = A A
How would we define an instance of NFData for this type? Any reduction to normal form of the A type would simply result in non-termination, so there is no real point in defining rnf for this datatype. It does not have a normal form that we can practically use.
Another problem are references used in monadic contexts. Would rnf evaluate the reference or the referenced value? (The standard implementations for IORef and STRef are only strict in the reference NOT in the value!). This ambiguity makes deriving the NFData instances impossible! If you want to create your own reference types you might want to avoid this confusion alltogether and simply not implement NFData and forbid strictness.
It's true that, when using some library that does not implement the NFData instances, you need to do it yourself (I atleast don't know of any automatic ways to do it). Sometimes, lazy evaluation forces us to not be lazy after all. :P
@@philipphagenlocher Ahhh so it's like Eq or Ord in that it seems like there should be an obvious one right way to do it, but in reality there could be multiple or no sensible ways for unusual things; thanks! :>
(Still though, there's a simple field-by-field 'deriving' default implementation for Eq and Show and Read and etc. that we just accept only works for like 90% of cases or something, and you have to manually write it when it doesn't. It seems like NFData could have that as an option too. But on the other hand, idk maybe the set of standard typeclasses for "deriving" was fixed before NFData was standard so it wouldn't have mattered?)
Do you have a video on semigroups/monoids? I can't find much out there that clearly explains what they are - I've flicked through your playlist briefly but cant see anything :(
They are planned! The roadmap for the next few videos looks like this: Parallelism -> Profiling -> Category Theory (which will probably span multiple videos talking about semigroups, monoids, functors, applicatives and monads again) -> Lambda Calculus -> Formal Proofs
Recently I watch the Tsoding video about creating music with Haskell th-cam.com/video/FYTZkE5BZ-0/w-d-xo.html
This is a /kinda/ real application, and it presents a way to create music (wave files) from scratch. I suppose this format could be used from time to time to present real-life examples of the different notions you teach, in a fun and practical way.
I might do that in the future!