Are you having trouble understanding haskell? Study this video for a month. His explanations are in perfect English and you listen to him think out loud; his THOUGHT PROCESS IS VERY CLEAR. No textbook can give you that. Great teacher !! OUTSTANDING
I want to add something VERY IMPORTANT here: this code as it’s written in this video won’t work. It will run in an infinite loop and never finish The problem is with the many function and definitions like in fmap and the applicative map operator. The way Haskell works involves some lazy evaluation, which means that expressions are evaluated as they are needed. If you unpack the definition as so “(Parser p1)” etc., Haskell will evaluate the contained function p1 before determining what needs to be executed with the given string. This means that, for a recursive call like in many, the program will continue to evaluate the full implementation of the function without knowing when to stop. To fix this, change the instances of (Parsel p) to just p and use runParser p to call the function. This way Haskell will only evaluate the function implementation when it’s given text argument and hence know when to stop.
Me, a dirty C#, Java, Javascript, Typescript programmer: uh huh, you did some weird functional haskell stuff, when are you gonna get to the parsing? Haskell: runParser (stringP "null") "null" Just ("","null") Me: Alright, what the fuck is this black magic?
Holy crap, you just covered the first half of my functional programming course in one video (Functors, Applicatives, Monads, Parsing) and I understood more than I did in all my lectures combined. Props man, if I pass it's all cuz of you.
This video got me huge into Haskell, I gave up on Learn You a Haskell when I got to applicatives but you made something so cool and elegant with them that I had to go back and keep learning. Now I can follow along everything you're saying, Haskell has changed how I look at programming
it’s nice that learn you a haskell is free but it’s not really a great book IMO. i have no idea why the first pages of the book are all haskell syntactic sugar and other garbage that has nothing to do with the core of what haskell is (the language) and how to program with the core of the language
@@michaelthompson7217 agreed. I'm not really sure who LYaH is for, tbh I guess it might be okay when it's used in a University course, alongside a lecture and some assignments-I end up referring to it sometimes, for examples of things, and I guess it would serve a similar function for someone who has to pass a class
The way you explain this make this easy to understand. The irony of this is that by not trying to look like a genius, by keeping to a simple style, you actually show your intelligence. Well done. Please do make some more content like this!
Just a small caveat: Applicative has some laws that can't be expressed in Haskell code. So the proof that it is Applicative is not complete with just the implementation. But usually the obvious implementation does satisfy the laws.
@@unsafecast3636 According to hackage.haskell.org/package/base-4.14.1.0/docs/Control-Applicative.html A valid applicative needs to satisfy the following laws, some of which are not expressed in the implementation. This means you could write an Applicative instance of a type and have it compile in Haskell, but it doesn't necessarily mean it's mathematically a lawful / valid applicative. Identity: pure id v = v Composition: pure (.) u v w = u (v w) Homomorphism: pure f pure x = pure (f x) Interchange: u pure y = pure ($ y) u
haskell hurts my brain, but learning it has been so fantastic, I'm getting a new perspective on programming, and this video has been a great resource for that
I came back to this 2 years later, now I'm actually doing a bachelor's thesis on a compiler using Haskell and this was such a great video, it's even better now that I understand Haskell and compilers better If it wasn't for you Tsoding I probably wouldn't have discovered my passion for programming language design, I remember tuning in to all of the Porth streams and trying to implement it in C++ myself Thank you so much ❤
Hey man, really appreciate your taking the time to step through your intuitions especially. There's one thing to know the theory of a programming language. But the real test is being able to construct a program with it. Cheers!
Same. It was very hard understanding functional programming a few weeks ago, before I started learning haskell. Now it feels really nice, this guy knows what he's doing.
My favorite thing about this channel is that it takes me like 6 hours to follow along with a 2 hour long video haha. The level of detail is absolutely incredible, we're very lucky to have this content just online like this
I found your video looking for some Haskell tutorials and I am amazed on how well you explain everything. Thank you! My favourite video on Haskell for now.
I was intrigued by Haskell and decided to follow along with you as you code. Was able to understand a good chunk of it without needing any course or tutorial. Thank you for your efforts!
Amazing video. I've used parsec/attoparsec/megaparsec to build parsers, but how they work was always somewhat of a mystery to me. Watching you build a parser from scratch was incredible, and all the little insights along the way were so valuable.
I tried to keep my serious face when you kept saying "penetration", but I absolutely lost it when you said "double penetration" Awesome video though! Thanks
This video is absolutely fantastic. I miss my time playing with Haskell... always forgot ':r', too. I would have loved this level of content 8 years ago :). Amazing, man, just amazing.
Legendary video. Worth noting that this approach can also be followed in imperative languages (Javascript, anyone?) and leads to an incredibly succinct way of implementing parsers.
I would be incredibly grateful if you could evolve this into a small series. Much like you start with Functor and move towards Applicative and Monad in implementation, if this could start with an Applicative and move towards an implementation using Monad and then MonadTs. It would still be a JSON parser each time, just showcasing how you would do it with each abstraction. edit: This was a great video, thank you
Спасибо за то, что показали, как реализовать синтаксический анализ в Haskell. Не зная Haskell, я решил попробовать разобрать XML для альтернативного языка разметки. Вы обеспечили отличное основание.
Praise our Haskell Wizard Overloard! All jokes aside, this was a really fascinating video that I'll probably rewatch later to learn more from. I've been using C for a class and I miss the rich abstractions in Haskell. It's kinda jarring going from one mindset to the other. In C you can accomplish the same things but with structs, loops, pointers, etc. I imagine working in C helps one reason about performance better in a HLL like Haskell and working in Haskell helps one identify useful abstractions for coding in a lower level language like C.
I was just looking for an excuse to learn how to parse stuff in haskell but didn't know where to begin... Thanks man, this was amazing!!! Looking forward to get more haskell wisdom
Understandable, is probably the weirdest of them all. I think the problem is that it does way too many things: 1. It merges the Applicatives. 2. It applies the function of the right applicative to the value of the left applicative. It's really unintuitive what would you use such combination of actions for. Use case example at 41:30 is probably the best thing I could come up with. Sorry if I could not explain it better. I also initially didn't understand why would you need , but over time after working with Maybe-s a lot I eventually sort of realized what it's meant for.
Pure functions perform calculations. But sometimes you want to have not only pure calculations but side effects as well. Functors, applicative functors, and monads are exactly about it: about performing pure calculations AND/OR side effects. Let's take for example Double. Pure functions should be deterministic, it means they have to be defined for all possible operations with Doubles. But what if you divide a Double by zero? Dividing by zero is not defined, and the result of it is out of the set of Doubles. Thus, with Maybe Double you perform EITHER pure calculations by getting (Just result) OR perform a side effect (in our case it is Nothing). The Parser from the video is an example of performing pure calculations AND (instead of OR which we have seen with Maybe Double in the example above) side effects. When we parse the string we get the result of the pure calculation (the second element of the tuple) AND a side effect (the rest of the string as the tuple's first element). Now it is easy to grasp the notion of the () operator (it calls "apply"). You have two entities, and each of them performs pure calculation AND a side effect. When you "apply" the first of it to the second with the help of () operator, you need to perform pure calculations with both second values of tuples AND sequentially perform 2 side effects (to return the rest of the string from the first parser and to return the rest of the rest of the string from the second parser). So you are parsing the input string with the first parser (and get a tuple (the_rest_of_the_string, pure_function)), and then parse the_rest_of_the_string with the second parser (and get a tuple (the_rest_of_the_rest_of_the_string, pure_function_applied_to_value)). Hope it will help you to understand.
And later in the video, you will encounter 2 more operators from Applicative: (). The first operator () ignores the value of the first parser and takes the value of the second parser but performs side effects of both parsers as well.
The way I kinda wrapped my mind around it is this: Imagine this: let a = (5+) let b = 5 In Haskell, everything is a function, and a and b can easily be combined with the expression a b. >a b 10 But not everything is a nice pure function. Sometimes you have Applicatives, like Maybe. Consider this: let a = Just (5+) let b = Just 5 You can no longer just do (a b) to get 10. Since Maybe is Applicative, however, we know that we can turn "inside out" the contents and evaluate the function of one with respect to the value of another. >a b Just 10 The result is an Applicative as well, an assertion that has been unadulterated by our . I've almost certainly oversimplified it but I hope the explanation makes it clearer.
This is such a good video, thanks so much :) A question though, wouldn't a monadic interface for Parser make it easier to read and write combinators? Especially with do-notation...
I guess it's a personal preference. I personally like the Applicative style better because the set of resulting parsers sort of resembles BNF in structure :D
Are you aware of ghcid --allow-eval mode? With it you can evaluate as many conditions as you like using "-- $> " so you just need to save the file and the expression will be evaluated bellow the "all good" confirmation, instead of having a tab bellow just to type some code to have it evaluated.
I’ll give a pogchamp. As a java programmer, this looks like black magic. Though I oddly understood some of it. I appreciate the explanations of everything. Not to mention the result was incredible I am impressed.
Hello Tsoding, long time no see. This is helpful for me to better understand the usage of the Maybe-monad we have begun using at my job (C#). There is no better way than you showing how it works in the OG functional language. Thank you for the great content. Hope you are well.
I would enjoy seeing you make a parser for some binary format (exe, mp3, png...) using parser combinators made by hand or from a major library, or hand-made recursive descent, in one of the new languages such as Rust.
Really great video! Just wanted to ask: Isn't your Parser type (if you made it a Monad) just an instance of State? i.e. Parser a is the same as State String (Maybe a)?
at 34:30, the issue was that f was already bound as the functor fmap is supposed to apply, and thus was unavailable as a valid local placeholder. Always keep your scopes in mind
hoooolyyyyy ...!!!1111 you just helped me implement a parser for the first time and I am buzzed about it :D I got up to 1:39:25, now I am going to grab a beer and drink it with you talking the last 10 mins to celebrate xD p.s. you are a swell and entertaining dude
Awesome video!!!! Thank you for taking the time to do this!!!! I have a question though: In the code below instance Functor Parser where fmap m (Parser p) = Parser $ \input -> do (input', x)
I have 0 idea what are you doing, and honestly it looks more like some forbidden language to summon demons, but I watched it almost to the end just because it is entertaining. I might get into Haskell after this :D
Every time you say "for the next parser", it would have been good to reinforce how `>>=` works. For a newbie Haskeller seeing that a parser returns `Maybe (String, a)` would make it hard to see how another parser with type `String -> Maybe (String, a)` could accept that because they would probably be thinking in terms of the "raw" types.
I haven't done haskell before but I followed this whole video. I have a lot of experience with imperative languages so functional programming is kinda confusing to me. I don't understand the specifics of all this but I understand what it does. I found this video very relaxing. :) Good job!
I Implemented a JSON Parser with C and took me around 1000 Lines, as JSON is a context free language, and is not a regular Lagrange, you need a push down automaton to implement it, additionally this push-down automaton, need 34 states, I am really surprised that you need just 111 lines to implement it since Haskell is more complicated than C/C++. I have troubles learning Haskell, because it is a ridiculously complicated language.
`sepBy` можно легче определить через `many`, поскольку `many parser` парсит 0 или больше вхождений. Таким образом: sepBy :: Parser Char -> Parser JsonValue -> Parser [JsonValue] sepBy sep parser = many (many sep *> parser)
Alright I've watched this so many times now and another Haskell thing just clicked, I think. Since everything in Haskell is lazy by default, there isn't really a functional difference between a Parser and an "unwrapped" parser that's already been run. That's so cool - - encoding data in advance before we even know what it is!
Are you having trouble understanding haskell? Study this video for a month. His explanations are in perfect English and you listen to him think out loud; his THOUGHT PROCESS IS VERY CLEAR. No textbook can give you that. Great teacher !! OUTSTANDING
My thoughts exactly! I've read lots of Haskell books and even written a clumsy parser, but this guy is amazingly good in explaining things
"Study this video for a month" this statement doesn't give Haskell a very nice look.
And I still won't know how to indent properly SO IT COMPILES (1:35:03)
i studied it for a month. still didnt understand. moving on to php now.
@@andrewbuzz7308 just use a formatter.
I want to add something VERY IMPORTANT here: this code as it’s written in this video won’t work. It will run in an infinite loop and never finish
The problem is with the many function and definitions like in fmap and the applicative map operator. The way Haskell works involves some lazy evaluation, which means that expressions are evaluated as they are needed. If you unpack the definition as so “(Parser p1)” etc., Haskell will evaluate the contained function p1 before determining what needs to be executed with the given string. This means that, for a recursive call like in many, the program will continue to evaluate the full implementation of the function without knowing when to stop. To fix this, change the instances of (Parsel p) to just p and use runParser p to call the function. This way Haskell will only evaluate the function implementation when it’s given text argument and hence know when to stop.
this is some extremely high quality content
absolutely. I heard "emacs" and despite already assigning this guy the "dope tech 'tuber" label he gets the rare "speaks to my soul" label too
Couldn't agree more. Great channel!
Me, a dirty C#, Java, Javascript, Typescript programmer:
uh huh, you did some weird functional haskell stuff, when are you gonna get to the parsing?
Haskell:
runParser (stringP "null") "null"
Just ("","null")
Me:
Alright, what the fuck is this black magic?
Holy crap, you just covered the first half of my functional programming course in one video (Functors, Applicatives, Monads, Parsing) and I understood more than I did in all my lectures combined. Props man, if I pass it's all cuz of you.
did you pass?
Where do you study?
@@krishnasivakumar2479 yep, managed to get it done haha
@@solopernumeri2 University of Toronto
@@Ahmad-if1tt awesome, kudos! What was your grade?
This video got me huge into Haskell, I gave up on Learn You a Haskell when I got to applicatives but you made something so cool and elegant with them that I had to go back and keep learning. Now I can follow along everything you're saying, Haskell has changed how I look at programming
it’s nice that learn you a haskell is free but it’s not really a great book IMO. i have no idea why the first pages of the book are all haskell syntactic sugar and other garbage that has nothing to do with the core of what haskell is (the language) and how to program with the core of the language
@@michaelthompson7217
agreed. I'm not really sure who LYaH is for, tbh
I guess it might be okay when it's used in a University course, alongside a lecture and some assignments-I end up referring to it sometimes, for examples of things, and I guess it would serve a similar function for someone who has to pass a class
I'm glad you explained the runParser thing. So many tutorials gloss over why a 'field' in a 'struct' would be called runThing.
The way you explain this make this easy to understand. The irony of this is that by not trying to look like a genius, by keeping to a simple style, you actually show your intelligence. Well done. Please do make some more content like this!
Just a small caveat: Applicative has some laws that can't be expressed in Haskell code. So the proof that it is Applicative is not complete with just the implementation. But usually the obvious implementation does satisfy the laws.
I'm intrigued. Can you expand on this?
@@unsafecast3636
According to hackage.haskell.org/package/base-4.14.1.0/docs/Control-Applicative.html
A valid applicative needs to satisfy the following laws, some of which are not expressed in the implementation. This means you could write an Applicative instance of a type and have it compile in Haskell, but it doesn't necessarily mean it's mathematically a lawful / valid applicative.
Identity:
pure id v = v
Composition:
pure (.) u v w = u (v w)
Homomorphism:
pure f pure x = pure (f x)
Interchange:
u pure y = pure ($ y) u
@@chon-850oh okay. Thanks
"We need to prove that parser is penetrable"
-- Tsoding 2019
Can your python do that?
haskell hurts my brain, but learning it has been so fantastic, I'm getting a new perspective on programming, and this video has been a great resource for that
I came back to this 2 years later, now I'm actually doing a bachelor's thesis on a compiler using Haskell and this was such a great video, it's even better now that I understand Haskell and compilers better
If it wasn't for you Tsoding I probably wouldn't have discovered my passion for programming language design, I remember tuning in to all of the Porth streams and trying to implement it in C++ myself
Thank you so much ❤
Tsoding is just underrated
Hey man, really appreciate your taking the time to step through your intuitions especially. There's one thing to know the theory of a programming language. But the real test is being able to construct a program with it. Cheers!
I’m a C# dev so this Haskell stuff looks like black magic
same here, i'm trying to understand FP.
This paper from 1998 is an extremely nice introduction to lambda calculus www.cse.chalmers.se/research/group/logic/TypesSS05/Extra/geuvers.pdf
@@shubham.1172 Thanks
Same. It was very hard understanding functional programming a few weeks ago, before I started learning haskell. Now it feels really nice, this guy knows what he's doing.
fsharpforfunandprofit.com/posts/understanding-parser-combinators/ might be more approachable if you know or planning to learn F#
I'm intrigued about the Porn Folder indicator on the status bar
lol i just saw it
Where do you think the double penetration implementation lives!?
My favorite thing about this channel is that it takes me like 6 hours to follow along with a 2 hour long video haha. The level of detail is absolutely incredible, we're very lucky to have this content just online like this
next video: how to implement a haskell compiler in haskell.
That could be great.
What's this, Lisp without parentheses?
@@stefanalecu9532 I don't know LISP enough to answer.
That's the most ... descriptive ... explanation of a functor I've ever heard. Thank you.
I found your video looking for some Haskell tutorials and I am amazed on how well you explain everything. Thank you! My favourite video on Haskell for now.
I was intrigued by Haskell and decided to follow along with you as you code. Was able to understand a good chunk of it without needing any course or tutorial.
Thank you for your efforts!
Amazing video. I've used parsec/attoparsec/megaparsec to build parsers, but how they work was always somewhat of a mystery to me. Watching you build a parser from scratch was incredible, and all the little insights along the way were so valuable.
You've just popularized hole-driven development :)
Not surprising, given the amount of penetration in this video. 🙃
I tried to keep my serious face when you kept saying "penetration", but I absolutely lost it when you said "double penetration"
Awesome video though! Thanks
This video is absolutely fantastic. I miss my time playing with Haskell... always forgot ':r', too. I would have loved this level of content 8 years ago :). Amazing, man, just amazing.
Nice haskell session. I just started learning it and it's interesting for me to see how your coding workflow is.
Legendary video. Worth noting that this approach can also be followed in imperative languages (Javascript, anyone?) and leads to an incredibly succinct way of implementing parsers.
This is Fcking Amazing!
I would be incredibly grateful if you could evolve this into a small series. Much like you start with Functor and move towards Applicative and Monad in implementation, if this could start with an Applicative and move towards an implementation using Monad and then MonadTs. It would still be a JSON parser each time, just showcasing how you would do it with each abstraction.
edit: This was a great video, thank you
Thank you for taking the time to do this. It’s incredibly detailed and informative
Спасибо за то, что показали, как реализовать синтаксический анализ в Haskell. Не зная Haskell, я решил попробовать разобрать XML для альтернативного языка разметки. Вы обеспечили отличное основание.
Для
парсинга есть библиотека parsec.
Это почти тоже самое,что он показал в видео.
I don't even program in Haskel let alone any functional language but when I do I sure as hell will watch your videos!
Praise our Haskell Wizard Overloard! All jokes aside, this was a really fascinating video that I'll probably rewatch later to learn more from. I've been using C for a class and I miss the rich abstractions in Haskell. It's kinda jarring going from one mindset to the other. In C you can accomplish the same things but with structs, loops, pointers, etc. I imagine working in C helps one reason about performance better in a HLL like Haskell and working in Haskell helps one identify useful abstractions for coding in a lower level language like C.
I was just looking for an excuse to learn how to parse stuff in haskell but didn't know where to begin... Thanks man, this was amazing!!! Looking forward to get more haskell wisdom
JS dev be like, I made chat apps, typed 10k lines in 2 mins.
Haskell deb be like, I made Parsers, only 111 lines in 2 hours.
JS dev here. I have no idea what I am watching.
The chat is not silent - it is speechless!
This is absolutely amazing content. Thank you for this, please keep up the good work man!
I lost it at around 45 minutes when you introduced operator...
Understandable, is probably the weirdest of them all. I think the problem is that it does way too many things:
1. It merges the Applicatives.
2. It applies the function of the right applicative to the value of the left applicative.
It's really unintuitive what would you use such combination of actions for. Use case example at 41:30 is probably the best thing I could come up with. Sorry if I could not explain it better. I also initially didn't understand why would you need , but over time after working with Maybe-s a lot I eventually sort of realized what it's meant for.
Pure functions perform calculations. But sometimes you want to have not only pure calculations but side effects as well. Functors, applicative functors, and monads are exactly about it: about performing pure calculations AND/OR side effects.
Let's take for example Double. Pure functions should be deterministic, it means they have to be defined for all possible operations with Doubles. But what if you divide a Double by zero? Dividing by zero is not defined, and the result of it is out of the set of Doubles. Thus, with Maybe Double you perform EITHER pure calculations by getting (Just result) OR perform a side effect (in our case it is Nothing).
The Parser from the video is an example of performing pure calculations AND (instead of OR which we have seen with Maybe Double in the example above) side effects. When we parse the string we get the result of the pure calculation (the second element of the tuple) AND a side effect (the rest of the string as the tuple's first element).
Now it is easy to grasp the notion of the () operator (it calls "apply"). You have two entities, and each of them performs pure calculation AND a side effect. When you "apply" the first of it to the second with the help of () operator, you need to perform pure calculations with both second values of tuples AND sequentially perform 2 side effects (to return the rest of the string from the first parser and to return the rest of the rest of the string from the second parser). So you are parsing the input string with the first parser (and get a tuple (the_rest_of_the_string, pure_function)), and then parse the_rest_of_the_string with the second parser (and get a tuple (the_rest_of_the_rest_of_the_string, pure_function_applied_to_value)).
Hope it will help you to understand.
And later in the video, you will encounter 2 more operators from Applicative: ().
The first operator () ignores the value of the first parser and takes the value of the second parser but performs side effects of both parsers as well.
I get it now... Thanks!
The way I kinda wrapped my mind around it is this:
Imagine this:
let a = (5+)
let b = 5
In Haskell, everything is a function, and a and b can easily be combined with the expression a b.
>a b
10
But not everything is a nice pure function. Sometimes you have Applicatives, like Maybe. Consider this:
let a = Just (5+)
let b = Just 5
You can no longer just do (a b) to get 10. Since Maybe is Applicative, however, we know that we can turn "inside out" the contents and evaluate the function of one with respect to the value of another.
>a b
Just 10
The result is an Applicative as well, an assertion that has been unadulterated by our .
I've almost certainly oversimplified it but I hope the explanation makes it clearer.
This is magic. Thanks for keeping my hope high on learning haskell and parsers.
You made me open my notes on Monoidal Categories, something not even the professor in that course managed to do
Definitely the most useful explanation on applicatives. Super cool
Pleeease dont stop posting content you're so cool and such a good informative teacher
Good video.
It shows how haskell abstractiobs can help us to express our functions or data types.
This tutorial complements real well with The Haskell Book's chapter 24 on "Parser Combinator".
thank you for this video, it really helped with functors and applicatives!
mind blown at 1:00:10
imma go back and rewrite my scheme implementation using all of what I've learned here cause man this is epic
Every parser related video, i closed it off before minute 10. Yours is super quality content man. Very intuitive the way you explain. nice!
charP could also have been implemented as
charP x = Parser f
where
f x:ys = Just (ys, x)
f _ = Nothing
58:00 Why not just implement "jsonBool" as:
JsonBool ((True
Ah, I see in the GitHub repo that at some point you did kinda the same.
I was thinking (const True) stringP "true" because I didn't know about
Lol I was thinking the same thing and glad someone 4 years ago thought the same
This video served me a perfect parser combinator tutorial. Vielen Dank!
I've learned so much from this man! More videos like this please!
I got this recommended and I just had to watch it
Как же мне не хватало этих видео лет 10 назад, Спасибо!
this is the best video i have seen on youtube in my entire life
hundred times better than a college course. thank you
Wow you make it seem so effortless 🤩
This is the best intro video for parser combinators I know of.
charP '!' *> applause
This is such a good video, thanks so much :)
A question though, wouldn't a monadic interface for Parser make it easier to read and write combinators? Especially with do-notation...
I guess it's a personal preference. I personally like the Applicative style better because the set of resulting parsers sort of resembles BNF in structure :D
You could use the language extension ApplicativeDo
Fantastic video. 10/10. I wanted to learn to program in Lean, and this was such a blessing.
I studied Haskell in class. Loved the language but didn't continued learning it. Makes me want to go back to it.
Are you aware of ghcid --allow-eval mode?
With it you can evaluate as many conditions as you like using "-- $> " so you just need to save the file and the expression will be evaluated bellow the "all good" confirmation, instead of having a tab bellow just to type some code to have it evaluated.
I’ll give a pogchamp. As a java programmer, this looks like black magic. Though I oddly understood some of it. I appreciate the explanations of everything. Not to mention the result was incredible I am impressed.
I enjoyed seeing you program in Haskell even though I am a beginner, you made the process seem fun, thank you
To make it really functional, I thought that one could use a function from String -> JsonValue for the JsonObject constructor. What do you guys think?
Wouldn't you end up using an associative list or a Map for the function anyways?
Любое видео по функциональному языку: ничего не понятно, но очень интересно
One day I'll understand this whole vid.
Hello Tsoding, long time no see. This is helpful for me to better understand the usage of the Maybe-monad we have begun using at my job (C#). There is no better way than you showing how it works in the OG functional language. Thank you for the great content. Hope you are well.
Impressive tutorial, very in-depth and well explained.
"Maybe is already an Alternative. May be we can take advantage of that" :D 56:00
I would enjoy seeing you make a parser for some binary format (exe, mp3, png...) using parser combinators made by hand or from a major library, or hand-made recursive descent, in one of the new languages such as Rust.
You could probably do a similar thing but using Attoparsec instead, since it's specialized on binary formats
This was literally the first thing I tried when I started learning Haskell, it took me closer to 200 lines though lol
Awesome video. I'm going to share this with all my coworkers. Please keep up the great content!
Moar like this, please :) Good stuff, tsoding.
what is this "P*rn Folder" thing in your bar? :p Great video brother! Love it
Really great video! Just wanted to ask: Isn't your Parser type (if you made it a Monad) just an instance of State? i.e. Parser a is the same as State String (Maybe a)?
I think he wanted to show how it works under the hood
at 34:30, the issue was that f was already bound as the functor fmap is supposed to apply, and thus was unavailable as a valid local placeholder. Always keep your scopes in mind
Крутое видео, спасибо!
Data.Map (containers) was never in base, but containers _is_ part of the haskell platform
hoooolyyyyy ...!!!1111
you just helped me implement a parser for the first time and I am buzzed about it :D
I got up to 1:39:25, now I am going to grab a beer and drink it with you talking the last 10 mins to celebrate xD
p.s. you are a swell and entertaining dude
Double penetration operation is my favourite new applicative related term haha
Great video on implementing a simple parser combinator.
Awesome video!!!! Thank you for taking the time to do this!!!!
I have a question though:
In the code below
instance Functor Parser where
fmap m (Parser p) = Parser $ \input -> do
(input', x)
Very nice! Excellent explanations as you go along too.
This was incredible, thank you for making it ❤
Someone nominate this guy for an award
I have 0 idea what are you doing, and honestly it looks more like some forbidden language to summon demons, but I watched it almost to the end just because it is entertaining. I might get into Haskell after this :D
As my professor once told us, Haskell is basically a DSL for implementing parsers.
Haskell is the way
Haskell is the way
This video is awesome, but it also scares me. It really sounds complicated.
Every time you say "for the next parser", it would have been good to reinforce how `>>=` works. For a newbie Haskeller seeing that a parser returns `Maybe (String, a)` would make it hard to see how another parser with type `String -> Maybe (String, a)` could accept that because they would probably be thinking in terms of the "raw" types.
I haven't done haskell before but I followed this whole video. I have a lot of experience with imperative languages so functional programming is kinda confusing to me. I don't understand the specifics of all this but I understand what it does. I found this video very relaxing. :) Good job!
God damn wizard
I Implemented a JSON Parser with C and took me around 1000 Lines, as JSON is a context free language, and is not a regular Lagrange, you need a push down automaton to implement it, additionally this push-down automaton, need 34 states, I am really surprised that you need just 111 lines to implement it since Haskell is more complicated than C/C++.
I have troubles learning Haskell, because it is a ridiculously complicated language.
It's fun and very informative. I really appreciate it!
`sepBy` можно легче определить через `many`, поскольку `many parser` парсит 0 или больше вхождений. Таким образом:
sepBy :: Parser Char -> Parser JsonValue -> Parser [JsonValue]
sepBy sep parser = many (many sep *> parser)
Только ты sep поставил перед,а значит возможен такой случай:
[ ,1,2,3]
Awesome stuff. Learned a lot, thanks!
Most educational haskell video this!
Congrats, you have done very good job here :)
Alright I've watched this so many times now and another Haskell thing just clicked, I think. Since everything in Haskell is lazy by default, there isn't really a functional difference between a Parser and an "unwrapped" parser that's already been run. That's so cool - - encoding data in advance before we even know what it is!