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
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?
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.
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.
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!
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 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
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
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 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 ❤
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
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 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!
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.
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.
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.
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.
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
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.
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.
Спасибо за то, что показали, как реализовать синтаксический анализ в Haskell. Не зная Haskell, я решил попробовать разобрать XML для альтернативного языка разметки. Вы обеспечили отличное основание.
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
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
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.
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.
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
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.
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 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
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)?
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.
Can't you use alternative to parse floats and things, so that if parsing a float, with a decimal point, fails, then it tries to parse the value as an integer?
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)
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!
`sepBy` можно легче определить через `many`, поскольку `many parser` парсит 0 или больше вхождений. Таким образом: sepBy :: Parser Char -> Parser JsonValue -> Parser [JsonValue] sepBy sep parser = many (many sep *> parser)
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.
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!
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.
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?
know thyself lol
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.
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?
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!
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 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
I'm glad you explained the runParser thing. So many tutorials gloss over why a 'field' in a 'struct' would be called runThing.
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
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 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 ❤
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
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 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!
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.
That's the most ... descriptive ... explanation of a functor I've ever heard. Thank you.
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 don't even program in Haskel let alone any functional language but when I do I sure as hell will watch your videos!
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'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!?
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.
Thank you for taking the time to do this. It’s incredibly detailed and informative
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
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’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#
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.
"We need to prove that parser is penetrable"
-- Tsoding 2019
Can your python do that?
This is absolutely amazing content. Thank you for this, please keep up the good work man!
Спасибо за то, что показали, как реализовать синтаксический анализ в Haskell. Не зная Haskell, я решил попробовать разобрать XML для альтернативного языка разметки. Вы обеспечили отличное основание.
Для
парсинга есть библиотека parsec.
Это почти тоже самое,что он показал в видео.
Nice haskell session. I just started learning it and it's interesting for me to see how your coding workflow is.
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
This is magic. Thanks for keeping my hope high on learning haskell and parsers.
You've just popularized hole-driven development :)
Not surprising, given the amount of penetration in this video. 🙃
Every parser related video, i closed it off before minute 10. Yours is super quality content man. Very intuitive the way you explain. nice!
Pleeease dont stop posting content you're so cool and such a good informative teacher
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
You made me open my notes on Monoidal Categories, something not even the professor in that course managed to do
this is the best video i have seen on youtube in my entire life
Definitely the most useful explanation on applicatives. Super cool
This is Fcking Amazing!
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
Good video.
It shows how haskell abstractiobs can help us to express our functions or data types.
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.
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.
thank you for this video, it really helped with functors and applicatives!
Tsoding is just underrated
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.
hundred times better than a college course. thank you
The chat is not silent - it is speechless!
This video served me a perfect parser combinator tutorial. Vielen Dank!
I've learned so much from this man! More videos like this please!
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
This is the best intro video for parser combinators I know of.
This tutorial complements real well with The Haskell Book's chapter 24 on "Parser Combinator".
Wow you make it seem so effortless 🤩
Fantastic video. 10/10. I wanted to learn to program in Lean, and this was such a blessing.
I enjoyed seeing you program in Haskell even though I am a beginner, you made the process seem fun, thank you
I studied Haskell in class. Loved the language but didn't continued learning it. Makes me want to go back to it.
Awesome video. I'm going to share this with all my coworkers. Please keep up the great content!
Как же мне не хватало этих видео лет 10 назад, Спасибо!
Крутое видео, спасибо!
charP could also have been implemented as
charP x = Parser f
where
f x:ys = Just (ys, x)
f _ = Nothing
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.
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
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
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 got this recommended and I just had to watch it
This was literally the first thing I tried when I started learning Haskell, it took me closer to 200 lines though lol
Moar like this, please :) Good stuff, tsoding.
Impressive tutorial, very in-depth and well explained.
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
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
"Maybe is already an Alternative. May be we can take advantage of that" :D 56:00
Любое видео по функциональному языку: ничего не понятно, но очень интересно
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?
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
what is this "P*rn Folder" thing in your bar? :p Great video brother! Love it
Very nice! Excellent explanations as you go along too.
Data.Map (containers) was never in base, but containers _is_ part of the haskell platform
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!
One day I'll understand this whole vid.
Great video on implementing a simple parser combinator.
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.
This was incredible, thank you for making it ❤
Congrats, you have done very good job here :)
It's fun and very informative. I really appreciate it!
charP '!' *> applause
Can't you use alternative to parse floats and things, so that if parsing a float, with a decimal point, fails, then it tries to parse the value as an integer?
Most educational haskell video this!
This looks like voodoo magic, where to start learning?
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)
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!
Someone nominate this guy for an award
Awesome stuff. Learned a lot, thanks!
As my professor once told us, Haskell is basically a DSL for implementing parsers.
`sepBy` можно легче определить через `many`, поскольку `many parser` парсит 0 или больше вхождений. Таким образом:
sepBy :: Parser Char -> Parser JsonValue -> Parser [JsonValue]
sepBy sep parser = many (many sep *> parser)
Только ты sep поставил перед,а значит возможен такой случай:
[ ,1,2,3]
Trying to make one in C++ code is a mess I have no idea what I am doing
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.
49:40 to 49:48 had me laughing so hard 😂 this is amazing thank you