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. :-}

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! :-(

ajb@spamcop.net wrote in article <20071014210605.4azxorgis4oso400@webmail.spamcop.net> in gmane.comp.lang.haskell.cafe:

That's not my experience. I didn't really understand Kalman filters until I read the Wikipedia page. It's better than most of the tutorials out there.

While we're off topic, here's a nice introduction to Kalman filters: http://www.cs.unc.edu/~welch/kalman/maybeck.html -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Inspired by http://www.xkcd.com/327/, I am considering changing my name to Chung-chieh ');DROP TABLE EMPLOYEES;-- Shan to see if anything breaks

@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 :) ========================================================================

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

jerzy.karczmarczuk@info.unicaen.fr 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.

...

...

...

...

"jerzy" == jerzy karczmarczuk writes:

[...] jerzy> But, when J. Vimal "threateneds us" to throw away Haskell, jerzy> complained about monads, and most people confirmed that the jerzy> underlying theory is difficult, ugly, and useless, I began jerzy> to read those postings with attention, since I disagree jerzy> with spreading such atmosphere. And A.C. additionally wrote jerzy> that all this theory has nothing to do with Haskell, and jerzy> submitted three more postings, one more dubious than the jerzy> other, I found that a warning seems suitable, not for him, jerzy> but for his readers! I'm an (almost) complete newbie to FP and for a beginner I don't see some "right" in myself to criticize "theory" being hard. I'm a CS guy without any background in Category Theory and related ideas, but when I see something elegant, I think I recognize it, and monads seem to be much elegant way of doing things than "usual" I/O. (And because of this elegance I couldn't persuade myself to learn OCam'l etc. first) Currently I can't say I understand monads, but as Von Neumann put it, "Young man, in mathematics you don't understand things. You just get used to them." ;) jerzy> Mathematics is beautiful and useful. The commutativity of jerzy> some categorical diagrams can be translated into the jerzy> optimization of Haskell constructs, say, showing that there jerzy> is a canonical isomorphism between jerzy> (map f) . (map g) and: map (f . g) jerzy> etc. So, why dump the theory away, which suggests jerzy> additionally that the conceptors of Haskell are jerzy> irresponsible dreamers, living on some crystal jerzy> mountain?... The language is not trivial to learn, that's jerzy> it. If somebody feels discouraged, my own students often jerzy> are, then the recipe is simple: ask CONCRETE questions, get jerzy> CONCRETE answer. THEN generalize. I asked Paul Hudak a few days ago about an exercise in his Haskell SOE book and I got more than I expected. (Prior to that, I asked in #haskell and also got more than I expected, though not understood all of them ;)) jerzy> But if some people offer general answers, they must be jerzy> based on a real competence and experience, otherwise they jerzy> easily become harmful. Being friendly is one thing, but being sensitive about the information is much more valuable IMO. I thank you for deciding to post this "disclaimer" instead of overlooking, which is perhaps the easier way. jerzy> ============== jerzy> "David48" points out that if a list returns the reader to jerzy> the docs which he has already seen, and which is poor, then jerzy> it doesn't work at all. OK, then, once more, don't say "I jerzy> cannot understand monads", or rewriting, or whatever, but jerzy> say plainly: "I read XYZ in the ABC tutorial, and the jerzy> example PQR remains too difficult." And say WHAT doesn't jerzy> work. jerzy> Go ahead, criticize *concrete* documentation, don't say jerzy> that docs are lousy! Almost all Haskell documentation has jerzy> been written by people who *beg* constantly for comments, jerzy> for criticism; let's help them instead of shouting at them. jerzy> Of course, the repeated, ever and ever again questions mean jerzy> that one day it will be absolutely necessary to make a true jerzy> FABQ, proposed a few times, and still in statu nascendi... I'm 27 years old and somehow programming for ~12 years in almost all major imperative languages. (I have some Scheme & Lisp experience also.) As another poster mentioned, this language gave me long forgotten excitement of programming again. Though I feel myself too lazy to cope with problems (and obstacles in learning and changing mindset) sometimes, and I usually don't understand topics in this mailing list most of the time, I don't attribute these to difficulty of the language. This is my laziness, not Haskell's. If I would like to program in "more understandable" ways, I know there are lots and lots of other languages that I can use, but trying to come up with a solution and seeing how succint it can be amazes me in this language and I don't know if I can be a successful Haskell programmer (and write those haikus you write here and there), but at least I'll try to be and if I can't, this will be my laziness, not Haskell's. Thanks and best regards, E.

On Oct 14, 2007, at 23:13 , Richard A. O'Keefe wrote:

(5) Precisely because it seeks generality, category theory seems difficult to "concrete thinkers". And books on category theory tend to be extremely fast-paced, so ideas which are not in themselves particularly esoteric (which may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them.

I would really like to see "category theory for the working *non*mathematician". I have essentially zero formal programming/CS- theory or mathematical training, and while sucking knowledge up like a sponge is often a good thing (especially for me as a practicing sysadmin), it does leave me at a bit of a disadvantage when you start maximally generalizing everything in sight at me, especially when you do so in esoteric mathematical language that leaves me going "buh?" -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

G'day all. Quoting "Richard A. O'Keefe" :

(5) Precisely because it seeks generality, category theory seems difficult to "concrete thinkers". And books on category theory tend to be extremely fast-paced, so ideas which are not in themselves particularly esoteric (which may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them.

I agree, but I don't think it needs to be this way. Books on category theory tend to be written for mathematicians or computer scientists who already grok the things that need generalising, even understand in a general sense how they're similar, and really just need to learn the language to express what they already know. In one respect, this makes sense (you learn the concrete, then you learn how to abstract away the details), but it also raises the barrier to the point where in learning mathematics, you're really learning history. Mathematics isn't immune from this, of course. Many scientists in disparate fields have complained that textbooks for their fields are really history books in disguise, and the material is more confused and tedious than it needs to be as a result. Example complaints: http://insti.physics.sunysb.edu/~siegel/history.html http://jchemed.chem.wisc.edu/journal/issues/1998/jul/abs817.html Cheers, Andrew Bromage

You don't need to unsubscribe. Just avoid posting things that are totally wrong (at least without a warning). -- Lennart On 10/14/07, Andrew Coppin wrote:

jerzy.karczmarczuk@info.unicaen.fr 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 10/14/07, david48 wrote:

On 10/14/07, Lennart Augustsson wrote:

...

You don't need to unsubscribe. Just avoid posting things that are totally wrong (at least without a warning).

How would he know they're "totally wrong" ?

Thinking before hitting the Send button might be a good first step, as well as refraining from giving the impression of certainty when one isn't actually sure. A little knowledge can be a dangerous thing, and it can be hard for newbies to evaluate the credibility of an answer. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "There's no money in poetry, but there's no poetry in money, either." --Robert Graves

Correction, I'm also very interested in Haskell, and I even don't have a bachelor degree :-) I'm a completely self-educated kind-a-guy... Anyway, IMHO Haskell rocks! A year ago I kind of started to hate writing code, and that after 25 years of coding in imperative and object-oriented languages. But thanks to Haskell, I found the vibes again! Cheers, Peter Verswyvelen Hugh Perkins wrote:

You're picking on Andrew Coppin? That's insane. He's got a sense of humour, and he's a lay (non-phd) person.

Honestly, in one thread you've got "Haskell is misunderstood! Its the greatest language in the world! Why does no-one use it????" and in another you're insulting one of the few non-phds who's interested in the language. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hugh Perkins wrote:

You're picking on Andrew Coppin? That's insane. He's got a sense of humour, and he's a lay (non-phd) person.

Honestly, in one thread you've got "Haskell is misunderstood! Its the greatest language in the world! Why does no-one use it????" and in another you're insulting one of the few non-phds who's interested in the language.

Um... well... thanks for the unsolicited defence. Well anyway, as you can see, I'm back. Mainly because I have questions that I need answers for... For what it's worth, I think Haskell is the most fantastic programming language ever invented. I spend all my time thinking about it and using it. And it frustrates the hell out of me that 100% of the human population consider Haskell to be an irrelevant joke language. So I basically have this uncontrollably awsome thing in front of me that I spend all my time and energy interacting with... and nobody to talk to about it. This mailing list is the only place I know of that is inhabited by people who actually think Haskell is something worth persuing. However, apparently even here my enthusiasm is misplaced. I'm getting rather tired of being repeatedly flamed. So, in the interests of preventing any further incidents, I will limit myself to only asking specific questions that solicit a specific answer, and I will attempt to refrain from stating any opinion of any kind. Hopefully that way at least I'll get something useful from this list, and the other people reading it won't have to listen to me being flamed again... [Let the lurking begin...]

Brent Yorgey wrote:

Well anyway, as you can see, I'm back. Mainly because I have questions that I need answers for...

glad you're back. =)

This mailing list is the only place I know of that is inhabited by people who actually think Haskell is something worth persuing.

don't forget about the IRC channel!

That have talking on IRC now? ...damn it. That was an opinion... OK, I'll try harder in future.

Felipe Lessa writes:

On 10/17/07, Andrew Coppin wrote:

...

... And it frustrates the hell out of me that 100% of the human population consider Haskell to be an irrelevant joke language. ...

I feel this way as well, specially because one of the teachers here tell all students that Haskell is the slowest thing ever by comparing Fibonacci sequence implementations between C and Haskell *using Hugs*.

We shall thus understand that a teacher who likes Fibonacci, is a representant of of the 100% of the human population. On the other hand, Microsoft Research who pays some developers of Haskell (whose names I have forgotten) doesn't count at all. Very interesting. Jerzy Karczmarczuk

Felipe Lessa writes:

On 10/17/07, jerzy.karczmarczuk@info.unicaen.fr

...

We shall thus understand that a teacher who likes Fibonacci, is a representant of of the 100% of the human population.

Sorry if I didn't understand very well the tone of your message or if I wasn't clear enough, however what I was trying to say is that he makes up the mind of most of his students with the idea that Haskell is a toy language with poor performance and strange limitations.

My tone was obviously sarcastic, and the reason is that for ANY niche of human activity you may find lousy teachers. And - in my eyes - you shouldn't have agreed on such a pathological example that 100% of the human population consider Haskell a toy. Haskell is being taught in hundreds of places. That's all. We shouldn't advertize bad teachers. BTW., almost 100% of humanity don't care at all about the General Theory of Relativity. And *never did*. It didn't prevent Einstein from sleeping. Of course, this example is as silly as it is, but not more. J.K.

Dipankar Ray decided to invest himself after my last grumbling concerning the uselessnes of recalling that Haskell may be presented in schools in a very bad way.

JK, of course there are foolish teachers out there. I don't think Felipe was suggesting that this teacher had the right idea, nor that he himself was going to stop haskelling anytime soon. But when people in relative power say wrong things, it makes it harder for junior colleagues (or students) to establish credibility, with other colleagues and students.

I *never* implied that. I suggested only that - after the statement of A. Coppin that 100% of the world ignores/despises Haskell - coroborating such a statement by a clearly inadequate example is not serious.

You may be of the opinion that such colleagues and students are fools, or beyond help.

I would *NEVER* say that, and I never did. On the contrary, my philosophy addressed to young was always: be *proud* that you began to learn sthing, since you *progress*. Potentially, you are more valuable that old guys who know everything they think they need... (*) If I blessed Felipe, I am terribly sorry. But I will fight with all arms against our auto-flagellation, and the "victimization" atmosphere! This is a road to hell.

... and we should all cultivate self-confidence.

Yes, absolutely. Without exaggeration... Perhaps the Feynman's wife phrase which became the book title "What Do You Care What Other People Think" is not the way of selling Haskell, but - please - there is a well known personage in the Great Literature, somebody really nice, but *absolutely* bad example to follow: Eyore, the Winnie the Pooh friend...

You mention MS Research supporting the Simons - well, MSR does so in part because both of them (and their colleagues at MSR Cambridge) are tireless evangelists, who are fantastically generous with their time, ideas, and code.

Not only that, of course, there are plenty of tireless evangelists who got no support. I wanted to point out that there are people/institutions who dispose of non-negligeable resources, and who decided to *invest* in people who do - apparently - an ever unpopular branch of programming theory and practice. ++ (*) OK, an absolutely irrelevant anecdote. Quite a time ago, far east of Poland (now Ukraine). An old Jew enters a train in a small station at his shtetl, enter the compartment, and - shock: he sees therein two well known Rebbis, wise men, very famous in the region. Oh, my! thinks he, what a chance. Now I will learn something, since they will probably engage in an extremely profound and enlightening discussion. But hours pass, the train is slow, nothing happens... After three hours, our hero is worried. He dares to open his mouth: "Excuse me, Rebbe. I apologize for interrupting your meditation, but aren't you the well know Rabbi from Pinsk?" - Yes, indeed. "And other gentelman..., I know you as well! You are the most well known thinkers of the region. Now, please, tell me, why do you remain silent, having such an opportunity to exchange some ideas, points of view, etc. I really hoped I would profit from your presence, it would be a godly gift for me!" - "Well" - the Rabbi smiles. "You are right, we are wise men. My neighbour is really very, very wise. He knows everything. Actually, I know many, many things myself as well. Why should we waste time on discussions? We won't learn more... ===================== Jerzy Karczmarczuk

On Thu, 18 Oct 2007, jerzy.karczmarczuk@info.unicaen.fr wrote:

Felipe Lessa writes:

...

On 10/17/07, Andrew Coppin wrote:

...

... And it frustrates the hell out of me that 100% of the human population consider Haskell to be an irrelevant joke language. ...

...

I feel this way as well, specially because one of the teachers here tell all students that Haskell is the slowest thing ever by comparing Fibonacci sequence implementations between C and Haskell *using Hugs*.

We shall thus understand that a teacher who likes Fibonacci, is a representant of of the 100% of the human population.

Uh, Jerzy? You might want to consider this a variant of the idiomatic "nobody cares", which also isn't quite meant literally. -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

andrewcoppin:

Hugh Perkins wrote:

...

You're picking on Andrew Coppin? That's insane. He's got a sense of humour, and he's a lay (non-phd) person.

Honestly, in one thread you've got "Haskell is misunderstood! Its the greatest language in the world! Why does no-one use it????" and in another you're insulting one of the few non-phds who's interested in the language.

Um... well... thanks for the unsolicited defence.

Well anyway, as you can see, I'm back. Mainly because I have questions that I need answers for...

For what it's worth, I think Haskell is the most fantastic programming language ever invented. I spend all my time thinking about it and using it. And it frustrates the hell out of me that 100% of the human population consider Haskell to be an irrelevant joke language. So I basically have this uncontrollably awsome thing in front of me that I spend all my time and energy interacting with... and nobody to talk to about it. This mailing list is the only place I know of that is inhabited by people who actually think Haskell is something worth persuing. However, apparently even here my enthusiasm is misplaced.

Please drop by the irc channel! enthusiasm is always welcome there, and we're pretty much all obsessed too! -- Don

On 10/19/07, Valery V. Vorotyntsev wrote:

On 10/18/07, Don Stewart wrote:

...

Please drop by the irc channel! enthusiasm is always welcome there, and we're pretty much all obsessed too!

Maybe that's not The Right Thing(TM) to ask, but anyway. :)

My access the world outside the office's LAN is limited to ports 80 and 443. And chat.freenode.net lives on 6667.

Once upon a time I could access #haskell via IRC gateway @ irc.e.jabber.ru, but not know, for the reasons unknown.

Do you know of any 443:server, forwarding connections to chat.freenode.net:6667?

Thanks a lot.

If you have a web server somewhere you can use CGIIRC. That's what I did in a similar situation. http://cgiirc.org/ -- Johan

On 10/19/07, Valery V. Vorotyntsev wrote:

On 10/19/07, Johan Tibell wrote:

...

If you have a web server somewhere you can use CGIIRC. That's what I did in a similar situation.

http://cgiirc.org/

Thanks, Johan!

There is one at http://ircatwork.com/ And now I'm in. Thank you very much. :) -- vvv

On 15 Oct 2007, at 2:59 am, Vimal wrote:

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>

It is true that Haskell Monads are inspired by category theory. It is also true that all the operations you need for something to be a category theoretic monad are available for Haskell Monads. HOWEVER You don't need to know that. Many Haskell programmers not only don't understand anything much about categories, they will never understand anything much about categories, and it doesn't matter. (After years of study, I can now get *to* chapter 3 in the typical "introduction to category theory* book, but not *through* it.) The really amazing thing about the IO Monad in Haskell is that there *isn't* any magic going on. An level of understanding adequate for using the I/O and State monads stuff (that is, adequate for practically anything analogous to what you might do in another language) goes like this: A type constructor that belongs to the Monad class can be used to sequence actions over some kind of hidden state. Each of these actions has an effect and a value. For example, getChar has the effect of reading a character from standard input, and the character it read as its value. For example, putChar x has the effect of writing a character to standard output, and () as its value because there isn't anything else useful to return. All monad instances must provide fail msg msg is an error message; this reports an error. return value an action with value as its value and no effect act1 >> act2 the effect of (act1 then act2) and the value of act. THIS IS JUST LIKE SEMICOLON IN TRADITIONAL LANGUAGES. act1 >>= actf2 the effect of (act1 then (act2f x)) with the value of act2f x, where x is the value of act1. Each monad also typically comes with a function that takes an action and an initial state and performs the action and returns its value. That function's name usually starts with "run". For the IO monad, the hidden state is "the state of the world, including I/O devices", and the "run" step is done just outside your 'main' function. In order to have an I/O action performed you should ensure that it is chained into the sequence actions starting from main and linked by >> and >>= . That's really all you have to know. The I/O actions in Haskell look uncommonly like C, and if you can do I/O in C you *can* do I/O in Haskell without even knowing how to spell 'Category Theory'.

The really amazing thing about the IO Monad in Haskell is that there *isn't* any magic going on. An level of understanding adequate for using the I/O and State monads stuff (that is, adequate for practically anything analogous to what you might do in another language) goes like this:[...]

Yes, I am at the stage where I can understand most of whats going on, as you described it in your email. I was wondering if understanding Category Theory would help me model situations better. Thats all :) But for now, I guess I will stick with this. Assuming that its a black box and it does what its supposed to do.

Brian Hurt writes:

I'm going to offer an opinion here that's likely to be controversial (in this forum): people new to functional programming shouldn't learn Haskell first.

Great! So, there are at least two of us!

They should start with either Ocaml or SML first.

Or Scheme. Or *any* decent language, with functional tools. It is *exactly* what we tried to do with Python. Paying tribute to our pedagogical constraints, and teaching a language with a strong imperative taste, but using functional constructions as frequently as possible. Recursion, comprehensions, map/filter business (despite strong intentions of Guido V.R. of killing them...), etc. Also, higher-order functions, not so bad in Python, although sometimes curiously inefficient. But, anyway, splitting between the language and the basic techniques may be not so stupid. Hm. An Anglosaxon shouldn't say "techniques may not be so stupid"?... I agree with what Brian says next. But...:

In a similiar fasion, Ocaml allows you to write old fasioned impertive code when you need to just get something working. And as you have the time/inclination/need to, you can start playing with more advanced functional concepts, like purely applicative data structures, lazy evaluation, and even monads.

As far as the lazy evaluation is concerned, I would suggest then to jump to Haskell or to Clean, after just a few simple-minded exercices in other languages (the cons-stream, etc. in Scheme. Or, the generators in Python, which are in a sense "lazy objects"). Otherwise you will *never* get a taste of laziness. It is useful only if it is comfortable. Jerzy Karczmarczuk

apfelmus:

main n = print . sum . map read . take n . reverse . lines =<< getContents Amazing. And so easy to read and understand...

This reminds me of a student how asked me to convert a simple formula to approximate PI from C++ to Haskell. Even although I have over a decade of C++ experience, I could not immediately do it (okay, I also just gave a 3 hours non-stop lecture, so my brain was completely empty ;). But when he gave me the math formula, converting it to Haskell was just a matter of translating the math to Haskell, almost one-to-one.... And that's one of the reasons I want to stick to Haskell for a few more years (at least) :-) Peter

On 10/14/07, Prabhakar Ragde wrote:

...

main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of this program, if there are m lines of input and m >> n? Many thanks. --PR

'reverse' needs to go to the end of the list to start outputting, so it has to keep all elements in memory somewhere at least in one moment of time. That means that the program has space complexity of O(m) -- the other functions are all O(1) in terms of line count. You may try this version instead: main n = print . sum . map read . head . dropWhile (not . null . drop n) . tails . lines =<< getContents where I changed (take n . reverse) to (head . dropWhile (not . null . drop n) . tails). Yes, I cheated, I'm using Data.List =). With this version you keep only n lines in memory at any moment, so it has space complexity of O(n). Please anybody correct me if I'm wrong. Cheers, -- Felipe.

On 10/15/07, apfelmus wrote:

Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time.

map (drop n) . tails = tails . drop n

O(m*n) O(m)

Nice identity. I'll remember this one.

With this, we can write a function that returns the last n elements of a list in O(m) time and O(n) space as

lasts :: Int -> [a] -> [a] lasts n xs = head $ [x | (x,[]) <- zip (tails xs) (tails $ drop n xs)]

and use it as a drop-in replacement

main n = print . sum . map read . lasts n . lines =<< getContents

But that's a a two-liner now heh =). Thanks for your great postings, apfelmus. Cheers, -- Felipe.

Felipe Lessa wrote:

apfelmus wrote:

...

Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time.

map (drop n) . tails = tails . drop n

O(m*n) O(m)

Nice identity. I'll remember this one.

Oops, please don't because it's wrong :) Data.List> let xs = [1..3] Data.List> map (drop 2) . tails $ xs [[3],[],[],[]] Data.List> tails . drop 2 $ xs [[3],[]] The first one produces some extra empty lists at the end. In other words, the left hand side and the right hand side have different lengths length . map (drop n) . tails = (+1) . length but length . tails . drop n = (\k -> 1 + max 0 (k-n)) . length But the wrong version looks much nicer :)

Thanks for your great postings, apfelmus. λ(^_^)λ

Regards, apfelmus

Hi

...

main n = print . sum . map read . take n . reverse . lines =<< getContents

Could someone describe succinctly how to compute the space complexity of this program, if there are m lines of input and m >> n? Many thanks. --PR

The space complexity is the size of the file - i.e. of size m. reverse will buffer up all the lines before it gives any back, which is a well known property of reverse. You could rewrite (take n . reverse) as a function that only requires n lines of buffer. Thanks Neil

Or F#, if you know C#, which is the "OCaml for the .NET world". Now I immediately went from C/C++/C# to Haskell, and yes, that was (is) hard. For me, the book Haskell School of Expression did it... All you need is a good book and lots of patience... Brian Hurt wrote:

On Sun, 14 Oct 2007, Andrew Coppin wrote:

...

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.

I'm going to offer an opinion here that's likely to be controversial (in this forum): people new to functional programming shouldn't learn Haskell first. They should start with either Ocaml or SML first. If it makes it easier to accept this argument, you can consider Ocaml and SML as "Haskell with training wheels". And that the original poster, rather than giving up on Haskell, should instead put Haskell on the backburner and instead learn Ocaml (which is likely to be hard enough). Then, in a year or two, start taking another swing at Haskell.

The problem is that Haskell has a lot of big ideas that all come at you pretty much immediately. Learning a new language in a new paradigm is a lot harder than learning in a new language in a paradigm you already know. If you know Java or C#, it's not that hard to learn Python or Ruby, because you already know how to think in objects. The problem with going from a C/Java/Ruby paradigm to Haskell is that Haskell isn't just one paradigm shift, it's several all rolled into one: - Purely functional - Lazy - Monadic - Strongly typed

Each one of these has a huge impact in how you think about problems and design programs- I'd argue about as large an impact as Objects have. These are all good things (well, I'd admit to not being 100% sure about pure laziness), and knowing how to think in these paradigms is definately a good thing.

And the situation is worse with pure functional languages. When you move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to learn new data structures and new algorithms. A doubly linked list is still just a doubly linked list, still has the same properties, and still has more or less the same implementation. In addition to learning Haskell, you also need to relearn basic computer science. You need to learn what a realtime lazy catenable dequeue is, how to implement it, and why you need one, all the while struggling with the syntax, type errors, and all the other problems trying to learning a new language.

I mean, contemplate this trivial exercise for a moment: write a program that reads from stdin a series of numbers (one number per line), and writes out the sum of the last n numbers. This is a trivial problem, and I have no doubt that someone who knows Haskell better than I will reply to this email with a single line of code that does it. But just think for a moment the number of different paradigm shifts that you need to make to write this program in Haskell.

I'm not saying that it's impossible to go directly to Haskell, I'm saying that it's just very very hard.

Ocaml, meanwhile, is in many ways the C++ of the functional world. C++ was needed for object orientation to take off, because it allowed you to continue to program in plain old procedural C when you needed to get something done, and to play with OO concepts and ideas as you have the time/inclination/need. Then, once people became comfortable with objects and OO thinking, they were ready for the real OO languages.

In a similiar fasion, Ocaml allows you to write old fasioned impertive code when you need to just get something working. And as you have the time/inclination/need to, you can start playing with more advanced functional concepts, like purely applicative data structures, lazy evaluation, and even monads.

Brian

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org 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. ;-)

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?)

G'day all. Quoting Derek Elkins :

The first goal listed in the Haskell 1.0 Report is:

"It should be suitable for teaching, research, and applications, including building large systems."

Haskell was never intended to be solely a teaching or research language. (You didn't necessarily say that, but it is a widely held and propagated misconception.)

I'd argue that you're kind of both right. The purpose of Haskell (i.e. "Haskell 89") was to unify all of those Miranda-like systems into a single language that everyone could share. However, arguably the biggest imperatives for Haskell 98 was to remove features that would confuse undergraduates. Even though we may not like to admit it, H98 really is primarily a teaching/research language. If we were doing H98 today, I don't think that would happen. The "research" part is bigger and better than ever, but we seem to weight "applications, including building large systems" more highly than "teaching" now. Having said that, in retrospect, the clean break was probably for the best. H98 gave us a simpler core on which to add the glasgow-exts. There's some stuff from Haskell 1.3 that I miss, and I hope it will come back, but there's also stuff that we're better off without. Cheers, Andrew Bromage

G'day all. Quoting jerzy.karczmarczuk@info.unicaen.fr:

I have heard that a few times, not recently. This is really interesting, WHAT do you actually miss?

Off the top of my head, from H1.4, I miss: - MonadZero (a lot) - Some of the monad/functor-overloaded functions (quite a bit) - Record punning (slightly)

For me, from the ancient times, what I regret, but just a tiny bit, is that (:) is not an operator as any other, but a "syntactic construct".

I agree with that in principle; it's unfortunate that lists are "built in" as much as they are. But I can't say I really miss this.

Also, monadic comprehensions, which disappeared in order to remove too much of ambiguity...

Five years ago, I would have agreed. I'm over that now, and do-notation is more useful.

Anything else worth mentioning? What *negative* has been suppressed?

I mentioned the un-generalising of "map" above. That probably needs some justification. I think that the best evidence of why this was a mistake is the fact that many modules implement a namespace-overloaded "map". Data.Map.map springs to mind, but there are others. People want to write "map" instead of "fmap". We could have come up with an alternative name for the list-version of "map" and not showed "map" to newbies. (Having said that, some of the un-overloading was good. I'm happy, for example, to reserve "concat" for lists and use "join" for monads.) Cheers, Andrew Bromage

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.

hey, compilers do nothing but IO! they read sources, print error messages or write object files and executables. there is really no need to do any "unseen" computation at all! unless there is some visible effect on the file system or programmer console, any such "unseen" computation is wasted, and should be optimised away. .. just kidding, of course?-) if compilers seem more suitable for haskell, it may be because they have been studied for a long time, and while throughput is important, noone is likely to argue that the core of compilation is about reading or writing files. the focus in writing compilers is on designing, implementing and manipulating the internal representations of the source and object code represented externally as strings of chars and bytes. applying the same reasoning to your "most widely-used programs", we could say that their theory hasn't reached the same level as that of compilers (and so i'd remove data bases from your list, and editors are also reasonably well-understood). once their internal representations are better understood, programming again focusses on working with these internal representations (often called models), while IO reduces to a straightforward mapping from and to those internal representations that are closest to the external ones. claus