Dear Haskellers,
I have been trying my best to read about Haskell from the various tutorials available on the internet and blogs. I havent been following YAHT properly, so its always been learning from 'bits and pieces' scattered around. For most languages (like C/C++/Ruby/Python), the above approach has helped me. But for Haskell, it is failing. I like learning by comparison with other similar languages. This approach worked for me when I tried learning Python+Perl together. The nicer syntax and easier object-orientedness made me leave Perl behind and pursue Python. I also tried it for Haskell (Lisp+OCaml+Haskell together). The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. For e.g, I tried writing a terminal GTalk client for Python when I was learning it, and learnt so many features that way. I used to call this 'learning by need', and it worked, to the extent that I never knew how to take 'input' from the user, but knew how to write Objects in Python! (Since I never used input in that example :) I didnt want to repeat that mistake, so I made sure I would learn IO in Haskell, which initially turned out to be a disaster, due to the 'Moands' which sounded like 'Go Mads' to me. Then, I set out to learn Monads + Category Theory from a Math perspective. And since I haven't been introduced to abstract math (like Groups, etc.), I found this a little difficult. However I tried my best to understand the tiniest bit and waited for the tiniest spark that would enlighten me. It didn't work out. --snip-- Okay, so you might be wondering as to whats the whole point of this mail? Well, I am almost on the verge of giving up on something I really like to learn, just because I didn't go in the right order! So, I requested my institute to buy Dr. Graham Hutton's book. I would be getting hold of that quite soon, and am willing to start from the beginning. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. I have no need to hurry anything at this point of time. But after being introduced to the tiniest bit of Haskell, and after seeing such a large and active community here, and #haskell, I had the plan of conducting a Haskell Workshop, in our department (sometime in Feb next year, the dates have not been finalized). I just hope that I should be able to reach a substantial amount of familiarity with Haskell by that time! Sorry for the long mail, and pardon me if it was too boring. I just put my thoughts on <strike>paper</strike> a mail :) I did have a couple of ambitious projects in my mind when to help me learn Haskell. They were: 1. An online judge system (Like http://spoj.pl). I had already done one for contests that were held during our Technical festival here, using php. The ideas are laid out. All I had to focus on was learning Haskell. 2. A solver for the Peg-Solitaire. This was more of an academic interest. I have seen Richard Bird's presentation on 'How to write a functional pearl, with an example' and was quite impressed by it. But the actual modelling might be slightly tricky here, and I am yet to start off with it. Many thanks for your patience, Cheers, -- ~Vimal IIT Madras RLE :) encode = map (length &&& head) . group decode = concatMap (uncurry replicate) _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Hi
> Then, I set out to learn Monads + Category Theory from a Math > perspective. This is where you went wrong. I know none of this stuff and am perfectly happy with IO in Haskell. Read http://www.haskell.org/haskellwiki/Monads_as_Containers and then read lots of other Monad tutorials for Haskell. > So, I requested my institute to buy Dr. Graham Hutton's book. I would > be getting hold of that quite soon, and am willing to start from the > beginning. I'm not sure this covers IO in any great detail - it will be useful for general Haskell though. > 1. An online judge system > (Like http://spoj.pl). > I had already done one for contests that were held during our > Technical festival here, using php. The ideas are laid out. All I had > to focus on was learning Haskell. > > 2. A solver for the Peg-Solitaire. > This was more of an academic interest. I have seen Richard Bird's > presentation on 'How to write a functional pearl, with an example' and > was quite impressed by it. But the actual modelling might be slightly > tricky here, and I am yet to start off with it. I would try number 2 first. IO in Haskell can be tricky, especially while you are learning all the other bits of the language at the same time. Network stuff is also not as well developed in terms of libraries as something like Python - but something like HappS should be able to do a spoj clone easily enough. A better choice for an initial IO application might be something like "du", then moving to an online judge system later on. Thanks Neil _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Hi Vimal
> I didnt want to repeat that mistake, so I made sure I would learn IO > in Haskell, which initially turned out to be a disaster, due to the > 'Moands' which sounded like 'Go Mads' to me. > > Then, I set out to learn Monads + Category Theory from a Math > perspective. And since I haven't been introduced to abstract math > (like Groups, etc.), I found this a little difficult. However I tried > my best to understand the tiniest bit and waited for the tiniest spark > that would enlighten me. It didn't work out. In my opinion (other may think differently) it is not a good idea to learn IO by starting with trying to grasp the theoretical foundation for monads. In the beginning you should just view the IO monad as Haskell's way of doing imperative IO stuff. When you feel comfortable with Haskell IO, then try to learn a couple of other monads. Then maybe this article http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html about monad transformers. It is good because it do not try to explain the implementation details of monad transformers - just how you use them. When you have done all that, then you should be ready for all the details. > > --snip-- > > Okay, so you might be wondering as to whats the whole point of this > mail? Well, I am almost on the verge of giving up on something I > really like to learn, just because I didn't go in the right order! > > So, I requested my institute to buy Dr. Graham Hutton's book. I would > be getting hold of that quite soon, and am willing to start from the > beginning. > > Meanwhile, could anyone suggest if there was anything wrong in my > approach to learning Haskell/the other languages? I agree that the > learning methodology is something personal and I have to find out what > best suits me, but I would like to hear something from you, > Haskellers, too. As I wrote above, I think you are trying to understand too many details at once. Also a textbook can sometimes be helpful. But you also have a learning by doing approach, which I personally find very productive. And do not give up yet. Haskell has a lot to offer and I think it is well worth the steep learning curve. Cheers, Mads Lindstrøm _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> I like learning by > comparison with other similar languages. This approach worked for me > when I tried learning Python+Perl together. The nicer syntax and > easier object-orientedness made me leave Perl behind and pursue > Python. > I also tried it for Haskell (Lisp+OCaml+Haskell together). > This probably works quite well for mainstream programming languages (since they're all so similar), but is unlikely to work at all for Haskell (since, as far as I know, no other programming language on Earth is remotely like it - Miranda excluded). Even Lisp and Erland are nothing like Haskell, and they're supposedly based on the same ideas. > The next step I usually take in learning a language is, not to go by > the topics found in textbooks, but by taking real world examples and > then blindly try to solve it using that language as a tool. Not a bad way to learn to use a tool. You might want to stick to things that involve simple I/O and complex processing rather than the other way round though. ;-) (For example, I wrote a program that renders an animation of the solutions of a simple differential equation by numerical integration. The math is complex; the I/O just involves dumping millions of numbers into a big text file.) > I didnt want to repeat that mistake, so I made sure I would learn IO > in Haskell, which initially turned out to be a disaster, due to the > 'Moands' which sounded like 'Go Mads' to me. > For the longest time I couldn't remember whether it's "monad" or "monand"... but anyway, yeah, it's a common problem. It's not actually complicated ones you understand it; it's just that it's so abstract that it's hard to explain. It's a bit like trying to explain to somebody what a "magnet" is... it's not a complex concept, just hard to describe. > Then, I set out to learn Monads + Category Theory from a Math > perspective. Um... yeah, that probably won't work. As far as I know, Haskell's idea of "monad" has little to do with the theoretical concept. > Meanwhile, could anyone suggest if there was anything wrong in my > approach to learning Haskell/the other languages? I agree that the > learning methodology is something personal and I have to find out what > best suits me, but I would like to hear something from you, > Haskellers, too. > I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite system similar to Mathematica. It was quite easy to learn the basics. What took longer was learning to approach problems in the right way. The way you'd do things in an object oriented language is usually NOT the way you'd do it in Haskell. (Unless you enjoy making your life hard...) Unfortunately, that's all practice. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> I have been trying my best to read about Haskell from the various > tutorials available on the internet and blogs. > [...] > > So, I requested my institute to buy Dr. Graham Hutton's book. I would > be getting hold of that quite soon, and am willing to start from the > beginning. IMHO, the best way to learn Haskell is to learn it from a textbook. That's basically all there is to it :) I mean, the same goes for Theoretical Computer Science, Mathematics, Physics etc. I think that the key properties of a textbook are 1) printed on paper 2) well-written Of course, if a book doesn't have property 2), use another one. An online book satisfying 2) can be made satisfy 1) by printing it out. In other words, anything goes that fulfills 1) and 2). And since reading two textbooks (in parallel) is even better than reading only one, I'd additionally recommend Bird's "Introduction to Functional Programming using Haskell". For other books, see also http://haskell.org/haskellwiki/Books_and_tutorials#Textbooks Regards, apfelmus _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
I just started working in Haskell about 2-3 months ago, and I'm loving it.
I've programmed a lot in Scheme which I learned my freshman year in college, so that helped a lot with the difference between functional and oop languages, but as Andrew Coppin mentioned, Haskell is quite different even from Lisp/Scheme etc. By way of an annecdote, the other day, I was working on a problem in Haskell and having some problems getting types (I believe it was a problem of converting between different types of numbers) to match up correctly. Darnit, if I was doing this in Scheme, I thought, the types would just work themselves out, so I booted up DrScheme and started translating the code. It took me three times as long because of all the list comprehensions and laziness that I had started to use so automatically in Haskell. Anyway... let me get to some of your questions. > So, I requested my institute to buy Dr. Graham Hutton's book. I would > be getting hold of that quite soon, and am willing to start from the > beginning. So when I first started with Haskell, I started with the online tutorials, but got stuck with the Monad stuff. So I actually ordered this same book and read it cover to cover, and it helped a quite a bit, but I still needed some practical experience. I think the examples which compare parsing strings to doing IO are especially instructive with respect to understanding Monads. However, what I'm really missing at this point is how to write my own monads. (As a side note, I'm not entirely convinced that you need to write a lot of your own monads, but I'd still like to understand that) > The next step I usually take in learning a language is, not to go by > the topics found in textbooks, but by taking real world examples and > then blindly try to solve it using that language as a tool. For e.g, > I tried writing a terminal GTalk client for Python when I was learning > it, and learnt so many features that way. I used to call this > 'learning by need', and it worked, to the extent that I never knew how > to take 'input' from the user, but knew how to write Objects in > Python! (Since I never used input in that example :) I also agree about this, so I started looking for small projects on which to cut my teeth and really learn the basic concepts in Haskell well. Then I stumbled onto Project Euler (projecteuler.net). Its a whole bunch of math-related problems where you usually need to write a program to do some sort of search for numbers with specific properties or to find the number of combinations for some bizarre situation etc. It may or may not be your cup of tea in the sense that the problems themselves are a bit esoteric and you'll never use these programs again. However, I (have) found that: 1. These smaller exercises have really helped me learn some of the weirder syntax better (ex: list comprehensions are now a piece of cake) 2. A number of the exercises require you to come up with more than just a brute force search (or your program will take too long to produce an answer), so I've had to learn about various topics (ex: how to use arrays in a functional (non-imperitive) way to accomplish dynamic programming type tasks) 3. Haskell is ideally suited to doing mathy type problems. For example, the laziness feature of the language (something else that is entirely different from most main stream languages, and which I needed more practice with) allows me to implement (potentially) infinite searches in the same way as I implement finite searches. > > I didnt want to repeat that mistake, so I made sure I would learn IO > in Haskell, which initially turned out to be a disaster, due to the > 'Moands' which sounded like 'Go Mads' to me. A couple of my solutions to project euler required me to use hashtables (before I figured out how to use arrays functionally) so I've picked up a little of the IO stuff. Its... less than intuitive, and I avoid it at all costs... some of the problems have large input files. I parse them by hand into Haskell syntax to avoid making my program have to do IO. But you can definitly learn more about IO by doing it the "sane/intended" way. Haskell programs tend to be structured to restrict IO to the surface level of the program, and use purely functional ideas to solve the meat of the problem. This seems to be one of the major design features of the language. However, most widely-used programs (ex: web browsers, word processors, email programs, data bases, IDEs) tend to be 90% IO and 10% (or less) computation. This can make Haskell quite unweildy for solving these types of problems. On the otherhand, writing something like a compiler (which requires a small amount of IO - read a file(s), write results to a file - and a large amount of "unseen" computation - generating and optimizing code) is right up Haskell's alley. > > Then, I set out to learn Monads + Category Theory from a Math > perspective. And since I haven't been introduced to abstract math > (like Groups, etc.), I found this a little difficult. However I tried > my best to understand the tiniest bit and waited for the tiniest spark > that would enlighten me. It didn't work out. Yeah, I have a math background as well, and I'd even heard of Monads and Category Theory back when I was taking algebraic topology, so I thought I'd dive into that... didn't work for me either. -Dave Stigant _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
David Stigant wrote:
> Haskell programs tend to be structured to restrict IO to the surface > level of the program, and use purely functional ideas to solve the > meat of the problem. This seems to be one of the major design features > of the language. Yep, that's the idea. :-D > However, most widely-used programs (ex: web browsers, word processors, > email programs, data bases, IDEs) tend to be 90% IO and 10% (or less) > computation. This can make Haskell quite unweildy for solving these > types of problems. On the otherhand, writing something like a compiler > (which requires a small amount of IO - read a file(s), write results > to a file - and a large amount of "unseen" computation - generating > and optimizing code) is right up Haskell's alley. Au contrare... ;-) Let us examine "web browser" for a moment. Yes, it does some input (typically fetching resources by HTTP), and some output (mainly displaying stuff on your screen). But wait a moment there... For a typical web page, you might well have to perform all of the following operations: - Parse an XHTML file into a document tree. (That's pretty algorithmic.) - Parse multiple CSS style sheets, and apply them to the document. (This involves processing possibly-complex element selectors, observing inheritance relationships, and merging the properties from several sources into a single result set. That's A LOT of algorithm!) - Parse some JavaScript and execute it. (That's an entire programming language, remember.) Watch in horror is it uses the DOM to *modify* the XHTML data you just parsed and applied CSS to... - Load several JPEG files. (You might think that "load a JPEG file" is I/O, but really, getting the data into memory is just the beginning. You've got a file to parse, you've got an arithmetic code to decompress, and then you've got an inverse Discrete Cosine Transform to do. Again, LOTS of algorithm.) - Let us hope to God the page doesn't contain any SVG... (Think of the massacre!) - Perform final layout (frames, tables, justification, backgrounds, transparency...) and rendering to incorporate all this data into one huge bitmap that can be dumped into the framebuffer. OK, so if you wrote this program today, the JPEG part would probably be an external library. And SVG, if you supported it. But you get the point; there is A LOT of heavily algorithmic stuff happening there that has little or nothing to do with I/O. The browser is sucking in XHTML, CSS, JavaScript, JPEG, SVG and God only knows what else (XSLT, anyone?), doing a mountain of processing with it, and only then showing the final result on your computer screen. There's a lot more I/O than your typical compiler, but don't go thinking there's nothing algorithmic happening here. ;-) Similarly, any good "word processor" is going to have layout algorithms (would you like that left-justified or right-justified? what happens if you have several typeface sizes in the same block of text? how does text flow round images?), and possibly cross-referencing. Email programs need to efficiently store and retrieve user's mail, and often have search facilities (and even Baysian filters for eliding spam). Even a humble IDE usually has syntax recognition... So you see, they may not spend quite as much *time* on computation as a compiler does, but there's still plenty of *complexity* there. ;-) _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Neil Mitchell
Cool! Lots of opinion. Let me consider them one by one:
======================================================================== @Neil: > This is where you went wrong. I know none of this stuff and am > perfectly happy with IO in Haskell. Read > http://www.haskell.org/haskellwiki/Monads_as_Containers and then read > lots of other Monad tutorials for Haskell. > I tried this too, and this made some sense to me in the beginning. But, not enough to satisfy my curiosity! So, I tried to dig in ... > > So, I requested my institute to buy Dr. Graham Hutton's book. I would > > be getting hold of that quite soon, and am willing to start from the > > beginning. > > I'm not sure this covers IO in any great detail - it will be useful > for general Haskell though. > IO isnt the only problem. Monads + how to define your own Monads etc. Since Monad's arent just for IO, where else could it be used? (e.g. Stateful functions), but is that it? Is it possible for me to come up with an instance of a Monad to solve _my_ problem? Thats the kind of question I would like to answer :) > > I would try number 2 first. IO in Haskell can be tricky, especially > while you are learning all the other bits of the language at the same > time. Network stuff is also not as well developed in terms of > libraries as something like Python - but something like HappS should > be able to do a spoj clone easily enough. A better choice for an > initial IO application might be something like "du", then moving to an > online judge system later on. You are probably right. Mimicking *nix tools might be great fun to start off with :) > > Thanks > Thanks :) ======================================================================== _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
@Andrew:
> This probably works quite well for mainstream programming languages > (since they're all so similar), but is unlikely to work at all for > Haskell (since, as far as I know, no other programming language on Earth > is remotely like it - Miranda excluded). Even Lisp and Erland are > nothing like Haskell, and they're supposedly based on the same ideas. I didnt know this when I _started_ :) So, thats why I am learning Haskell in exclusion. > > Not a bad way to learn to use a tool. You might want to stick to things > that involve simple I/O and complex processing rather than the other way > round though. ;-) (For example, I wrote a program that renders an > animation of the solutions of a simple differential equation by > numerical integration. The math is complex; the I/O just involves > dumping millions of numbers into a big text file.) > Yes, as someone pointed out, Haskell was meant for a lot of computation, and IO is just a part of the story! > For the longest time I couldn't remember whether it's "monad" or > "monand"... but anyway, yeah, it's a common problem. It's not actually > complicated ones you understand it; it's just that it's so abstract that > it's hard to explain. It's a bit like trying to explain to somebody what > a "magnet" is... it's not a complex concept, just hard to describe. > But, being a computer science student, I think I need to look into it too! I like the quote found on this site: http://patryshev.com/monad/m-intro.html <quote> Monads in programming seem to be the most mysterious notion of the century. I find two reasons for this: * lack of familiarity with category theory; * many authors carefully bypass any mention of categories. It's like talking about electricity without using calculus. Good enough to replace a fuse, not good enough to design an amplifier. </quote> > > > > I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite > system similar to Mathematica. It was quite easy to learn the basics. > What took longer was learning to approach problems in the right way. The > way you'd do things in an object oriented language is usually NOT the > way you'd do it in Haskell. (Unless you enjoy making your life hard...) > Unfortunately, that's all practice. > Ah, I am not familiar with the "term-rewrite" you are talking about. I will Google it up then. Thanks :) ======================================================================== _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Mads Lindstrøm
>
> In my opinion (other may think differently) it is not a good idea to > learn IO by starting with trying to grasp the theoretical foundation for > monads. In the beginning you should just view the IO monad as Haskell's > way of doing imperative IO stuff. When you feel comfortable with Haskell > IO, then try to learn a couple of other monads. Then maybe this article > http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html > about monad transformers. It is good because it do not try to explain > the implementation details of monad transformers - just how you use > them. When you have done all that, then you should be ready for all the > details. Alright, this post seems interesting. Will try it out soon! > As I wrote above, I think you are trying to understand too many details > at once. Also a textbook can sometimes be helpful. But you also have a > learning by doing approach, which I personally find very productive. > Yeah, this has always been a problem with me. Its like browsing Wikipedia. Open an article, and you branch out like anything. Curiosity does kill the cat :( > And do not give up yet. Haskell has a lot to offer and I think it is > well worth the steep learning curve. > Nope. I enjoy learning it, just waiting to hit the peak! Someone creative enough should draw the learning curve for Haskell :D. I remember some funny ones for text editors! (emacs had a spiral...) _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Stigant
I think you have got a very good point in your mail that I overlooked
all along ... "Why was Haskell created?" is a question that I havent tried looking for a answer :) > I also agree about this, so I started looking for small projects on which to > cut my teeth and really learn the basic concepts in Haskell well. Then I > stumbled onto Project Euler (projecteuler.net). Its a whole bunch of Ah, yes, Project Euler. I did start doing this sometime back, but then gave up on it. Perhaps its time to start again :) Thanks, that was an eyeopener. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> Wikipedia. Open an article, and you branch out like anything. > Curiosity does kill the cat :( > > Yeah, this has always been a problem with me. Its like browsing Whenever I do this, I usually end up reading about something utterly unrelated. (Actually, I usually end up reading about things which are toxic, explosive, flammable or corrosive... hmm, That's Not Good...) I tried to use Wikipedia to learn about how to build digital filters... this was a disaster. There is almost no useful information there! :-( _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> IO isnt the only problem. Monads + how to define your own Monads etc. > Since Monad's arent just for IO, where else could it be used? (e.g. > Stateful functions), but is that it? Is it possible for me to come > up with an instance of a Monad to solve _my_ problem? Thats the kind > of question I would like to answer :) > I/O is a monad. Actually, there's another one called STM (for doing "transactional" modifications). And there are various ones for doing "stateful" stuff (e.g., incrimentally building a solution or something). Then there's the Maybe monad (for operations which sometimes fail). Lists are a monad (for operations that yield multiple results). Parsers are a celebrated example of monads - although the most efficient ones use something called "arrows". (These are like monads, but even more abstract. If you enjoy making your head hurt...) There is also an entire zoo of other monads out there. There's a CPS monad (for writing unmaintainable code), many graphics libraries have a "drawing monad"... the list goes on. Is there any merit in you writing your own monad? Well, if it's doing something similar to existing monads, then maybe. (Note that there are such things as "monad transformers", which allow you to merge multiple monads together into a giant, all-powerful monad. So, if you wanted a stateful parser that does I/O, you could use transformers to mix those exact features together - no coding required.) >> I would try number 2 first. IO in Haskell can be tricky, especially >> while you are learning all the other bits of the language at the same >> time. Network stuff is also not as well developed in terms of >> libraries as something like Python - but something like HappS should >> be able to do a spoj clone easily enough. A better choice for an >> initial IO application might be something like "du", then moving to an >> online judge system later on. >> > > You are probably right. Mimicking *nix tools might be great fun to start > off with :) > Uh... think it's been done already. ;-) Still, you could try it yourself and see what you get - and then marvel at how others have done it in half the code. :-} _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> I think you have got a very good point in your mail that I overlooked > all along ... "Why was Haskell created?" is a question that I havent > tried looking for a answer :) > To avoid success at all costs? (No, seriously. The basic idea was that there used to be about two-dozen languages like Haskell, but all developed by different people and all with different syntax and so on. So they wanted to create a single language suitable for teaching to students. You could say it's the Pascal of the functional world... Hey, maybe that explains the lack of success?) _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
Vimal wrote:
> @Andrew: > > But, being a computer science student, I think I need to look into it too! > I like the quote found on this site: http://patryshev.com/monad/m-intro.html > <quote> > Monads in programming seem to be the most mysterious notion of the century. > I find two reasons for this: > > * lack of familiarity with category theory; > * many authors carefully bypass any mention of categories. > > It's like talking about electricity without using calculus. > Good enough to replace a fuse, not good enough to design an amplifier. > </quote> > Maybe *this* is why I get nowhere with designing electronic things? I know very little about calculus. (And I can't begin to imagine what it has to do with electricity...) For what it's worth, a "category" is a "class" bearing some additional structure. A "class" is exactly like a "set", except that all sets are classes, but only some classes are also sets. There *is* a reason for this, but nobody knows what it is. (They say it's because some classes are "bigger" than sets - which is absurd since a set can be of any size...) > Ah, I am not familiar with the "term-rewrite" you are talking about. > I will Google it up then. > Thanks :) > A term-rewrite system is just a system that replaces ("rewrites") certain terms with other terms. For example, a package like Mathematica would have a term rewrite rule that says that all occurrances of "x - x" should be rewritten as "0". Haskell can't do anything quite *that* sophisticated, but what it *can* do is things like linear a b x = a*x + b which causes all terms involving "linear" to be rewritten into the thing on the RHS. You can actually draw the "reduction" sequence as an expression is transformed step by step into the final result: sum [1,2,3] foldr1 (+) [1,2,3] foldr (+) 1 [2,3] foldr (+) (1+2) [3] foldr (+) (1+2+3) [] 1+2+3 3+3 6 Each line is derrived from the previous one by some program rule. (The last three being hard-coded into the language itself.) If you're pathologically curiose, look up "lambda calculus" for a programming language like Haskell where the last few steps above are *definable* from first principles. >:-D _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
On 10/14/07, Vimal <[hidden email]> wrote:
> Dear Haskellers, > I have been trying my best to read about Haskell from the various > tutorials available on the internet and blogs. I havent been following > YAHT properly, so its always been learning from 'bits and pieces' > scattered around. You might try Erlang. It's easy like Python. It's designed for rock-solid enterprise applications. Threading and rpc are insanely easy. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Vimal-2
On 10/14/07, Vimal <[hidden email]> wrote:
> IO isnt the only problem. Monads + how to define your own Monads etc. > Since Monad's arent just for IO, where else could it be used? (e.g. > Stateful functions), but is that it? Is it possible for me to come > up with an instance of a Monad to solve _my_ problem? Thats the kind > of question I would like to answer :) The approach I used to fully understand monads was the same as I used to fully understand Python's metaclasses: don't try to get into its inner until you need. I mean, don't try to find a problem to come up with a monad. Instead, someday you will going to solving a problem and you'll have the idea of making "instance Monad" of it. Meanwhile you'll get used to the language and see lots of other already-built monads. Well, worked for me. The beautiful thing about monads and metaclasses is that they are extremely simple after you understand them. That's also why monads are called Warm, fuzzy things, AFAICT =). But both don't fit everywhere, and it requires some experience to see that. -- Felipe. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
I will be impolite.
Andrew Coppin says: > For what it's worth, a "category" is a "class" bearing some additional > structure. A "class" is exactly like a "set", except that all sets are > classes, but only some classes are also sets. There *is* a reason for > this, but nobody knows what it is. (They say it's because some classes are > "bigger" than sets - which is absurd since a set can be of any size...) If this were the first posting of A.C., I would suspect that he is pulling my leg, that his brilliant sense of humour surpasses my comprehension, so I should be filled-up with deep respect for such a wonderful mind. But enough is enough. Now, would it be really too much asking that - at least from time to time - Andrew Coppin think twice before saying things he - apparently - knows NOTHING about? Haskell café, is, well, café... even no tobacco restrictions. But, since we have here people who want to learn something structured and based on some real competence, saying e.g. that "CPS monad is for making unmaintainable code", or "I know very little about calculus. (And I can't begin to imagine what it has to do with electricity...)", is becoming a nuisance. I skipped the postings of A.C., as most of people on this forum I happen to know, and there was no personal reason to react. But A.C. engages in a dialogue with newbies, and this is, from the pedagogical point of view, rather harmful. Please stop. Another "example", for the rewriting this time: > foldr (+) 1 [2,3] > foldr (+) (1+2) [3] > foldr (+) (1+2+3) [] > 1+2+3 > 3+3 > 6 This "derivation" is pure rubbish. Read the definition of foldr, please, would it be the first time in your life??? The functional foldr is NOT tail recursive! And, actually, as EVERYBODY knows, Haskell is not a rewriting system. So, a good advice for J. Vimal: do whatever you wish, but avoid this fellow A. Coppin, since he leads you nowhere. Jerzy Karczmarczuk _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
[hidden email] wrote:
> I will be impolite. > > If this were the first posting of A.C., I would suspect that he is > pulling > my leg, that his brilliant sense of humour surpasses my comprehension, so > I should be filled-up with deep respect for such a wonderful mind. But > enough is enough. Now, would it be really too much asking that - at least > from time to time - Andrew Coppin think twice before saying things he - > apparently - knows NOTHING about? OK. I get the message. I'm unsubscribing now... [How ironic the subject line suddenly seems.] _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
[hidden email] wrote:
> I will be impolite. There was no need to. Andrew Coppin wrote: > OK. I get the message. I'm unsubscribing now... There was no need to. Please, let's keep haskell-cafe a friendly place, as it's always been. When someone posts inaccurate (or even wrong) facts: "Attack ideas. Do not attack people." (Please!) Regards, Zun. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |