[Haskell-cafe] Re: Tutorial uploaded
On 2005-12-20, Daniel Carrera [EMAIL PROTECTED] wrote: Hi all, I've finished a first draft of what I call First steps in Haskell. It's intended to be the very first thing a new user sees when they decide to try out Haskell. I should point out a parallel effort that a few of us have worked on from time to time: darcs get --partial http://darcs.complete.org/haskell-v8 Please feel free to darcs send any patches. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Tutorial uploaded
Hello Daniel, Wednesday, December 21, 2005, 6:34:10 PM, you wrote: DC You can show them this on the first page: DC main = do DC x - getLine() DC print my_program(x) this named `interactive` :) try: main = interactive(map toUpper) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Tutorial uploaded
Hello Bill, Wednesday, December 21, 2005, 6:38:33 PM, you wrote: BW PS: While looking over my post it occurred to me that the issue is at BW least as much methodological as it is linguistic. So I ask: Does BW Haskell stand far enough apart from other programming languages to BW warrant adapting standard methodological principles to it? Is there an BW identifiable Haskell Way? as the man, who learned Haskell just year ago, and written large enough imperative program in Haskell (you can see it at http://freearc.narod.ru), i can answer both yes and no. yes, Haskell really changes the way i program. no, it not diverges from the standard methodology - it forces to use it! :) any real program uses global variables, side-effects of functions, manually controlled sharing of data and so on. imagine programming in language which just don't support any provision for those tricks well, Haskell implementations de-facto supports such tricks, but they are considered as bad programming style and can lead to problems with optimized compilation, so you will aspire to avoid them as much as possible. you will need to decide beforehand for each function, whether it will have side effects or will be pure (although you of course may change your solution, whis will require to edit all functions which directly or indirectly call it, because function with side effects cannot be called inside pure function) you will need to learn programming techniques, which can be used in reliable way instead of forbidden unreliable ones - such as implicit parameters and using large structure to pass through the many levels of calls all data needed for these functions you will become an expert in organizing cycles via recursion ay least, you must try :) even if Haskell is not useful as real programming language, you at least will improve your programming style ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Hello Daniel, Thursday, December 22, 2005, 3:13:06 PM, you wrote: DC Well, I'm a newbie, and I wrote it. I have enough understanding to DC generate that code, even if I don't understand it all. This is what I know: please, don't learn Haskell!!! we will test different tutorials on you! :))) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Tutorial uploaded
Hello John, Thursday, December 22, 2005, 3:48:37 AM, you wrote: JM You can't not start with IO for people who already know how to program, JM if you are teaching someone programming for the very first time then JM starting with the pure functional side is fine. But for people that JM already know how to program, they are constantly thinking of everything JM else they have written and how they might do it in the language they are JM currently learning comparing and contrasting in their head. They need to JM have the tools to replicate what they have done with other languages JM right away, they don't want to know how to do the examples given in the JM book except insofar as they let them understand how to write the JM examples wiggling around in their head. yes, it's just about me :) first i time i tried to learn Haskell (afair, it was advertized on bzip2 page), i decided that it need to write everything as a pure function and found monad concept very complex (afair, gentle introduction emphasizes that monads are very complex things!). next time i tried to learn Haskell, my main question was is it possible to use imperative style of controlling program action?. i recognized functional power of language and it was the last barrier to really use it so, i think, it is needed to reassure imperative programmers at first pages by demonstrating techiques of imperative programming, including conditional execution and IORef/MArray and only after that present more convenient alternatives. at least for my imperative feel, conditional execution, cycles, modifiable variables and arrays together form enough basis to implement any algorithm -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tutorial uploaded
S Koray Can wrote: As a newbie... I agree that a newbie should be able to write this fairly early on: main = do x - getLine() putStrLn (The answer is ++ show(fib(read(x I'd agree for some definition of 'early'. I'll elaborate: [snip] The above code snippet contains typeclasses (show, read, monadic IO, lists), syntactic sugar (do, -). When you say a 'newbie' should be able to write that early on, I'd interpret that as 'a newbie should be able to regurgitate this early on' Well, I'm a newbie, and I wrote it. I have enough understanding to generate that code, even if I don't understand it all. This is what I know: * x is a string, fib wants an int, and read turns a string into a number. * The answer is is a string so you need ++. ++ expects a string, and show turns a number into a string. So, yes, I need *basic* knowledge of types (strings vs numbers) and the functions that convert from one to the other. But that's it. I don't need to know that do and - are syntactics sugar, or what a monad is (heck, I don't know those things). I think that the following is suitable for chapter 1: --//-- main = do putStrLn What is your name? name - getLine putStrLn(Hello ++ name) --//-- You don't need to learn about monads, or classes or lists for this. Yes, not even lists (Use ++ to catenate strings). All you need to know is strings, and that name - getLine gets a line from input and puts it in 'name'. I think that this is suitable for chapter 2: --//-- main = do putStrLn Please type a word: word - getLine putStrLn(This word has ++ (show( length word)) ++ letters) --//-- Here you learn about numbers, and converting numbers to strings (show). And this is for chapter 3: --//-- main = do putStrLn Please type a number: number - getLine putStrLn (number ++ ! = ++ (show (fac read(number))) --//-- Here you learn about converting a string to number. At some point between chapters 1 and 3 you'd learn how to write 'fac' (I guess chapter 1). Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/22/05, Daniel Carrera [EMAIL PROTECTED] wrote: S Koray Can wrote: As a newbie... I agree that a newbie should be able to write this fairly early on: main = do x - getLine() putStrLn (The answer is ++ show(fib(read(x I'd agree for some definition of 'early'. I'll elaborate: [snip] The above code snippet contains typeclasses (show, read, monadic IO, lists), syntactic sugar (do, -). When you say a 'newbie' should be able to write that early on, I'd interpret that as 'a newbie should be able to regurgitate this early on' Well, I'm a newbie, and I wrote it. I have enough understanding to generate that code, even if I don't understand it all. This is what I know: * x is a string, fib wants an int, and read turns a string into a number. * The answer is is a string so you need ++. ++ expects a string, and show turns a number into a string. Actually, it's a bit more than that (but still not harder than a newbie would be able to grasp in the first chapter). 'read' convertes a string into *any* readable value. So 'read (4,1.23,'c')' would convert a string into type '(Integer,Double,Char)'. Likewise 'show' converts any showable value to a string. This include numbers, but also includes a host of other values. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/22/05, John Meacham [EMAIL PROTECTED] wrote: Just the idea that you can write things like mapM and replicateM is enough to blow the mind of many impertive programmers. Not trying to fan the flames, but one thing I struggle with is understanding (at a gut level - if you explain the theory, I'll understand, but go away none the wiser in practice...) why I need mapM as well as map (and all the other -M functions, liftM, foldM, etc...) mapM and so on really *are* why the IO monad is a great feature of Haskell. But the mental gearchange needed to appreciate what just happened is one of the speedbumps on the learning curve. You thought you were getting along fine, you'd got the point of functional stuff like map and fold, and you understood IO and it wasn't as scary as you'd thought. But then along comes mapM, and you're struggling again - why not just use map? And the explanation doesn't help much, it just leaves you feeling that you'd missed the point. As I say, I'm not trying to criticize anyone here, but it seems to be quite hard to get across to people who have understood and assimilated this sort of stuff, just how hard it feels to newcomers. We understand the explanations (we do! really! :-)) but even understanding them, we are still left with a lack of confidence. It's like being shown a full set of carpentry tools, having every one explained, but still reaching for the hammer every time and banging something no matter what we're trying to do :-) Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Thu, 22 Dec 2005, Paul Moore wrote: ... FWIW, I don't really see why the -M functions are needed either. It's something to do with the fact that map is for lists, and mapM is for monads, which are a more general type of sequence than a list. But why mapM isn't therefore a superset of map, and so map is redundant, I don't know. This reminds me why I like Hugs - whether I normally use it or not, I have it installed so that I can refer to lib/Prelude.hs, my single most useful Haskell document. You can offer any number of conceptual explanations of these things, but there seems to be no way to guarantee that they're going to be taken the right way. The Prelude definitions may or may not make sense, but at worst I don't think they can muddy the issue. I'm also reminded that there we're talking about several distinctly different types of learning here. If you're taking a class, you might well profit from a structured sequence that focuses on the static declarative aspects first, avoids recursion, etc. If you're on your own - as commonly the case with people reading tutorials - it's important to present the language in a useful form as soon as possible, let there be a temptation to switch to the Objective CAML tutorial because of a mistaken impression. Donn Cave, [EMAIL PROTECTED] --- sequence :: Monad m = [m a] - m [a] sequence [] = return [] sequence (c:cs) = do x - c xs - sequence cs return (x:xs) sequence_:: Monad m = [m a] - m () sequence_ = foldr () (return ()) mapM :: Monad m = (a - m b) - [a] - m [b] mapM f= sequence . map f mapM_:: Monad m = (a - m b) - [a] - m () mapM_ f = sequence_ . map f ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Thu, Dec 22, 2005 at 02:02:56PM +, Daniel Carrera wrote: I had never heard of mapM, or other -M functions. I can't imagine why those would be needed. It seems like pointless duplication. (!!!) then you are missing out. the M functions (and monadic traversal functions in general) especially when combined with the mtl are some of the best swiss army knives haskell has to offer. and it is map that is redundant. map f xs = runIdentity $ mapM f xs sequence = mapM id I have come to think of the monadic forms of these functions as the 'true' versions and the others as just common special cases. though, not my most common function used from the prelude, it is up there. and the most commonly used non-trivial function other than return: 922 mapM 937 Nothing 1017 not 1061 error 1433 String 1456 Just 1544 IO 1777 map 1810 show 1972 text 2595 Int 5303 return John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/22/05, Daniel Carrera [EMAIL PROTECTED] wrote: Paul Moore wrote: As I say, I'm not trying to criticize anyone here, but it seems to be quite hard to get across to people who have understood and assimilated this sort of stuff, just how hard it feels to newcomers. We understand the explanations (we do! really! :-)) but even understanding them, we are still left with a lack of confidence. It's like being shown a full set of carpentry tools, having every one explained, but still reaching for the hammer every time and banging something no matter what we're trying to do :-) I had never heard of mapM, or other -M functions. I can't imagine why those would be needed. It seems like pointless duplication. mapM is like map except you map an IO Action over a list instead of a function of a list. For instance sizes - mapM getFileSize myListOfFileNames If you used map here you'd end up with a list of IO actions, and not a list of file sizes. You'd then have to go through this list of IO actions and using (-) on each element to get the file sizes. This can, incidentally, be done using the function 'sequence'. liftM lifts a function so that you can use a regular function on an IO Action instead of first having to extract the value of the IO action using (-). It's just shorthand, so you could do: x - liftM length (readFile afile) Instead of having to do f - readFile afile let x = length f The M functions really are useful, get to know them! /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
SKC This entire discussion is about 'breaking a cyclic graph of conceptual SKC dependencies'. Unfortunately, I don't think it can be done well in short SKC amount of time. I bet if we sat down and listed all the concepts required to write idiomatic Haskell (even idiomatic Haskell 98 (whatever this means)), to write programs that do the things that we all have done in other languages (you know what I'm talking about here, but of course this is up for debate too), we would see that it was not a linear structure but a cyclic graph or at best a tree of concepts: we need to understand higher order functions, polymorphic higher order types for monads, monads to understand I/O really well (or to understand WHY I/O in a purely functional language is the way it is), typeclasses, laziness, etc. etc. In a lot of situations, pedagogy is hard to 'linearize'. Why would it be any different in programming? especially in Haskell? A lot of learning Haskell is just helping reinforce this strong, but sometimes subtle base of knowledge required to really start to get Haskell. [1] HT Btw. Simon Thompson states in his book, that he found it didactically HT infelicitous to introduce recursion before higher order functions because HT that let beginners stick to case discriminations and recursive programming HT instead of taking advantage of functions like 'map', 'iterate', 'fold' HT etc. I can confirm this experience and I think that it is similar to IO HT vs. non-IO. It very well may be didactically infelicitous [2]. (I wish there were some program we can just run on a course syllabus and find out that something is felicitous): conceptsInHaskell :: [haskellConcept] conceptsInHaskell = [...] -- abstract main = print $ sort conceptsInHaskell .. error: haskellConcept not a member of class Ord. Maybe we'll (collectively) get better and better at this. I think we are. Hopefully experience and sharing this information will be beneficial to all (as well as discussion like these). Maybe it depends on who is learning Haskell, and why: maybe the 'conflict' is that learning to program *in* Haskell /= learning to program *with* Haskell. But maybe it's not ultimately an optimizable piece of data, the right order of teaching concepts in Haskell. Maybe it should be allowed to be more random-access? (I personally like things more that way :-) . Cheers Jared. -- [EMAIL PROTECTED] http://www.updike.org/~jared/ reverse )-: [1] Perhaps a point in Haskell's favor for pedagogy is that there are things you can do in Haskell that you just can't do (in the same, succint sense) in most programming languages, e.g. even OCaml. Maybe these things (and they are neat, simple things, like the code twos = 2:twos and then manipulating this infinite stream) can help motivate people to really want to grok Haskell, and to stick with it and use it for practical projects because of its many advantages. :-) [2] Paul Hudak does this in the Haskell School of Expression. He writes recursive code with cases, etc. and then in a later chapter explains how to rewrite it with map, fold, etc. Fine. It takes steps to learn how to write idiomatic Haskell. At least for me, the joy of Haskell is not in memorizing vocabulary (as is common in a language like Java, or C#) but rather, internalizing concepts. By writing ugly code at first and then seeing the patterns and refactoring with map and fold, I've personally internalized it (instead of learning some clever rule, up front, that I'll later forget). Think Why FP Matters by Hughes. He does this too (recursion, pattern matching, then later swapping in higher order functions), to explain why FP is so great. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Paul Moore wrote: Not trying to fan the flames, but one thing I struggle with is understanding (at a gut level - if you explain the theory, I'll understand, but go away none the wiser in practice...) why I need mapM as well as map (and all the other -M functions, liftM, foldM, etc...) All you really need to understand is what sequence :: Monad m = [m a] - m [a] does. Once you get that, the difference between map and mapM is clear because of mapM f xs = sequence (map f xs) Udo. -- Worrying is like rocking in a rocking chair -- It gives you something to do, but it doesn't get you anywhere. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Neil Mitchell [EMAIL PROTECTED] writes: I would have actually said Hugs, and especially the Windows front end WinHugs was a lot more suitable for beginners than GHC, but the wiki page very much gives the other impression. Which page are you referring to? I went to look, but couldn't find any page discussing the compiler/interpreter options with reasonable detail and focus. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Robin Green wrote: Henning Thielemann wrote: Starting with IO in Haskell is like starting LaTeX with rotating text and making it colorful. Not at all! Indeed IO _is_ complicated regardless of whether it is modelled by Monads in Haskell or differently in other languages. Rubbish! 10 PRINT WHAT IS YOUR NAME? 20 INPUT NAME IO isn't complicated in BASIC. I agree. Not that it's *really* complicated in haskell, though. I think all a tutorial needs to do is explain = means a definition, - means the left side is the result of the right side In order to show that x = getLine means that x is the function getLine while x - getLine means that x is the result of getLine Monads can come *way* later I think, but even then they're not difficult at all. Beginners should start with non-monadic functions in order to later avoid IO in their functions whereever possible. Whilst localising IO to a small part of the program is generally a good idea, beginners should not be scared off by the thought that IO in Haskell is so hard it has to be covered on page 94. This is not the case. It should be introduced on page 1. If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. I agree with this wholeheartedly. When I first started playing with Haskell, some of the tutorials made it look like it was very difficult to do anything practical with it because doing real input and output seemed like an advanced topic. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Robin Green wrote: Whilst localising IO to a small part of the program is generally a good idea, beginners should not be scared off by the thought that IO in Haskell is so hard it has to be covered on page 94. This is not the case. It should be introduced on page 1. As a newbie... I'll agree with Robin. I /did/ think that IO in Haskell was probably very difficult because it's covered in page 94. I skimmed through YAHT and IO is covered wyyy deep into the document. I haven't read that section yet, but there is a lot of content and to me it looked like it must be something difficult. I guess/hope that when I get around to reading it I'll find out that it's not as scary as it looks. If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. Until recently I thought of Haskell as something you would use for Calculus and the like. It seemed like a tool for academia. You may be interested to know that one of the reasons I started looking at Haskell just now was to help a friend understand Calculus (the other reason is that Haskell looks very cool). Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Robin Green wrote: If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. Strange, I always thought predictable, understandable and above all correct code would be the primary goal, with small and quick code coming later. To write interactive Haskell code well, you have to understand higher order functions. So the IO monad has to come late in any tutorial. Before that, IO should be restricted to the EVA principle (Eingabe, Verarbeitung, Ausgabe == Input, Processing, Output). It was a good principle in the 60s, and it still is. Unless you want to teach people to program as they would do in Basic, that is. Udo. -- You can pick your friends and you can pick your nose, but you can't pick your friend's nose. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Robin Green wrote: Henning Thielemann wrote: Starting with IO in Haskell is like starting LaTeX with rotating text and making it colorful. Not at all! Indeed IO _is_ complicated regardless of whether it is modelled by Monads in Haskell or differently in other languages. Rubbish! 10 PRINT WHAT IS YOUR NAME? 20 INPUT NAME IO isn't complicated in BASIC. IO is always complicated: It means sending messages, follow redirections, updating contents of windows, writing to disks etc. Nevertheless it may be easily accessible in some languages like BASIC. But it is important to separate IO from computations, also in languages where IO is easily accessible. Usually students start writing programs with much user interaction and it is hard to convince them of the advantages of programming interfaces. So I prefer starting a tutorial without IO, interaction in GHCi and Hugs should be enough for the beginning. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Creighton Hogg wrote: I agree with this wholeheartedly. When I first started playing with Haskell, some of the tutorials made it look like it was very difficult to do anything practical with it because doing real input and output seemed like an advanced topic. The drawback is that I saw many Haskell programs implemented with IO read/write functions which could be easily implemented without IO, using laziness. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Udo Stenzel wrote: Strange, I always thought predictable, understandable and above all correct code would be the primary goal, with small and quick code coming later. Depends on what you mean by quick and small. Do you mean that the program should execute fast and have a small memmory foot-print? If so, I agree. If what you mean is that the programmer should be able to finish the project quickly and it shouldn't have too many lines of code, then I think those features are important. To write interactive Haskell code well, you have to understand higher order functions. That's scary, that you need advanced knowledge just to do IO. Unless you want to teach people to program as they would do in Basic, that is. I don't know what you mean by that. Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Henning Thielemann wrote: IO is always complicated: I have never once thought it was complicated. All I've ever needed are print() and readLine() and those shouldn't be complicated IMO. And I wouldn't want to wait for page 120 to learn how to do that. My programs are not going to be useful if they can't get user input or produce output. I don't want to wait for page 120 to write my first useful program. So I prefer starting a tutorial without IO, interaction in GHCi and Hugs should be enough for the beginning. GHCi and Hugs are enough for the /beginning/ yes, but that doesn't mean that IO should go on chapter 7. How about putting it in chapter 2? Cheers, Daniel -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Henning Thielemann wrote: On Wed, 21 Dec 2005, Creighton Hogg wrote: I agree with this wholeheartedly. When I first started playing with Haskell, some of the tutorials made it look like it was very difficult to do anything practical with it because doing real input and output seemed like an advanced topic. The drawback is that I saw many Haskell programs implemented with IO read/write functions which could be easily implemented without IO, using laziness. Can you think of any examples of things like that? Given that I'm still learning how to take advantage of laziness it'd be pretty interesting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 21/12/05, Daniel Carrera [EMAIL PROTECTED] wrote: Henning Thielemann wrote: IO is always complicated: I have never once thought it was complicated. All I've ever needed are print() and readLine() and those shouldn't be complicated IMO. And I wouldn't want to wait for page 120 to learn how to do that. My programs are not going to be useful if they can't get user input or produce output. I don't want to wait for page 120 to write my first useful program. For this much, see my reply to your message in the other thread :) IO in Haskell isn't really so bad if you take it the right way. However, we do have these really nice interactive environments for evaluating expressions. When I write a real application, often the last thing I write is 'main'. It's more fun to start with the core of the algorithm that I want to implement, or problem I want to solve, and work my way outward to the user interface. So perhaps it's more natural for a Haskell tutorial to start there. As a Haskell programmer, it's where I'd start to write my program. So I prefer starting a tutorial without IO, interaction in GHCi and Hugs should be enough for the beginning. GHCi and Hugs are enough for the /beginning/ yes, but that doesn't mean that IO should go on chapter 7. How about putting it in chapter 2? Cheers, Daniel -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
-- Message: 1 Date: Wed, 21 Dec 2005 10:48:08 + From: Robin Green [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Re: Tutorial uploaded Beginners should start with non-monadic functions in order to later avoid IO in their functions whereever possible. Whilst localising IO to a small part of the program is generally a good idea, beginners should not be scared off by the thought that IO in Haskell is so hard it has to be covered on page 94. This is not the case. It should be introduced on page 1. If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. Couldn't agree more. I show my students IO in the first lecture of their first programming course in the first term of their first year. A few lectures later I discuss it in more detail, and tell to think of an IO a as instructions on a piece of paper to produce an a. My students have no difficulty understanding the difference between being given 500 crowns (a value), and being given my ATM card and code with instructions how to work an ATM! Haskell IO is mystifed far too often in my opinion--it needn't be hard at all. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Creighton Hogg wrote: On Wed, 21 Dec 2005, Henning Thielemann wrote: The drawback is that I saw many Haskell programs implemented with IO read/write functions which could be easily implemented without IO, using laziness. Can you think of any examples of things like that? Given that I'm still learning how to take advantage of laziness it'd be pretty interesting. Some example for writing a text the IO oriented way: do putStrLn bla replicateM 5 (putStrLn blub) putStrLn end whereas the lazy way is putStr (unlines ([bla] ++ replicate 5 blub ++ [end])) You see that the construction of the text is separated from the output, but the effect is rather the same in both variants: The text is constructed simultaneously with output. You could also make the separation explicit: text :: String text = unlines ([bla] ++ replicate 5 blub ++ [end]) main = putStr text ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Am Dienstag, 20. Dezember 2005 20:07 schrieb Sebastian Sylvan: [...] It's sometimes beneficial to lie a bit when starting out. Perhaps say something like this is a simplified view of things, for all the gory details see chapter 19. Monadic IO is pretty darn cool, sadly that means that many tutorial authors are tempted to spend pages upon pages explaining exactly why it's cool and how it works, but that is NOT what most people starting out with the language need to read. I'm still looking for a good *practical* tutorial that I could recommend to newcomers. IO, data types and QuickCheck in the very first chapter, I say! Real program examples from the get go, and go into the theory on why this has been hard in FP before Haskell (or Monadic IO rather) much much later, so as to not scare people away. I think that there are cases where it's better to start with ordinary functional programming and come to I/O later. In my opinion, an example case would be teaching Haskell at a university. /S /W ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Am Mittwoch, 21. Dezember 2005 11:48 schrieb Robin Green: [...] If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. So programming is only practical if it's deals with a lot of I/O? This is wrong, in my opinion. Take a compiler. The only I/O it does is some simple file I/O. The important part of the compiler doesn't deal with I/O at all. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Daniel Carrera wrote: Depends on what you mean by quick and small. Do you mean that the program should execute fast and have a small memmory foot-print? I was referring to Robin's mentioning space/time usage, so yes, that's what I meant. To write interactive Haskell code well, you have to understand higher order functions. That's scary, that you need advanced knowledge just to do IO. Actually not. You need advanced knowledge to *avoid* doing IO. (If higher order functions like map, fold count as advanced.) A good, readable, maintainable Haskell program is almost completely pure and does very little IO. Of course you can write an IO-heavy program in the same style you'd use in C, but it would be exactly as ugly. Unless you want to teach people to program as they would do in Basic, that is. I don't know what you mean by that. You will soon. Once you get used to composing functions instead of sequencing actions, you'll appreciate the difference. Udo. -- Disco is to music what Etch-A-Sketch is to art. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Creighton Hogg wrote: On Wed, 21 Dec 2005, Henning Thielemann wrote: The drawback is that I saw many Haskell programs implemented with IO read/write functions which could be easily implemented without IO, using laziness. Can you think of any examples of things like that? Given that I'm still learning how to take advantage of laziness it'd be pretty interesting. Here's another one: I've heard a fellow claim, Haskell is basically unsuitable to implement a compiler, because Haskell is weak at IO and everything needs IO, the lexer, the preprocessor, the parser, the pretty-printer, ... Can you imagine what convoluted mess he would write if he learned IO first? Therefore I think, if, say, chapter 6 includes A parser for Things is a function from Strings to a list of Things and Strings, then chapter 7 is the earliest that should include IO beyond getContents and putStr. The funny thing is, after the parser IO is simply another monad. At this point, the compiler becomes an imperative one-liner and lots of pure functions. Udo. -- I piss on you all from a considerable height. -- Louis Ferdinand Celine signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Robin Green wrote: I meant that for *many* but not all practical programming tasks, IO is important. ...web applications... Ha, wrong! A CGI script only needs getEnv, getContents and putStr, if it has persistent state, it also needs readFile and writeFile. Each of the five is called exactly once per invocation. The main function is boiler plate, the bulk of the logic is pure. Same for a web application server, only less IO. Compilers are atypical in this regard. You wouldn't believe what diverse applications could be summed up under compilers. Udo. -- If I ever write a GUI library for Haskell, I'm going to call it pointlesstif. -- Pseudonym on #haskell signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Am Mittwoch, 21. Dezember 2005 13:31 schrieb Daniel Carrera: Udo Stenzel wrote: Strange, I always thought predictable, understandable and above all correct code would be the primary goal, with small and quick code coming later. Depends on what you mean by quick and small. Do you mean that the program should execute fast and have a small memmory foot-print? If so, I agree. If what you mean is that the programmer should be able to finish the project quickly and it shouldn't have too many lines of code, then I think those features are important. I agree, and keeping the IO-part of your programmes small helps with that in my experience. And as Cale wrote, working from the pure core to the IO-coating is more fun (personal inclination, of course). But yes, people want to write interactive programmes soon, so I think Chapter 2: Basic I/O where putStr(Ln), print, getLine, getChar, maybe also readFile and writeFile/appendFile are introduced, do-notation and '-' are explained is a good idea. However, a section about Why a special IO-type, more comprehensive explanations to come and how to use Hugs/ghci to develop and test your algorithms should be definitely included. That's my tuppence, feel free to disagree. To write interactive Haskell code well, you have to understand higher order functions. That's scary, that you need advanced knowledge just to do IO. Unless you want to teach people to program as they would do in Basic, that is. I don't know what you mean by that. Cheers, Daniel. ditto! P.S.: In May, there was a 'Daniel Carrera' around, too. Isn't that a strange coincidence? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Udo Stenzel wrote: Unless you want to teach people to program as they would do in Basic, that is. I don't know what you mean by that. You will soon. Once you get used to composing functions instead of sequencing actions, you'll appreciate the difference. Ah. Yes, I do think I understand the difference (my math background is stronger than my programming background). Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/21/05, John Hughes [EMAIL PROTECTED] wrote: -- Message: 1 Date: Wed, 21 Dec 2005 10:48:08 + From: Robin Green [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Re: Tutorial uploaded Beginners should start with non-monadic functions in order to later avoid IO in their functions whereever possible. Whilst localising IO to a small part of the program is generally a good idea, beginners should not be scared off by the thought that IO in Haskell is so hard it has to be covered on page 94. This is not the case. It should be introduced on page 1. If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. Couldn't agree more. I show my students IO in the first lecture of their first programming course in the first term of their first year. A few lectures later I discuss it in more detail, and tell to think of an IO a as instructions on a piece of paper to produce an a. My students have no difficulty understanding the difference between being given 500 crowns (a value), and being given my ATM card and code with instructions how to work an ATM! Haskell IO is mystifed far too often in my opinion--it needn't be hard at all. You should write a book, or at least a tutorial series! :-) The order in which you deal with Haskell subjects in your course is, imo, very close to ideal. It emphasizes Haskell as a real-world pracical langauge, rather then making it look like an academic toy langauge which can't be used for anything real-world. As I mentioned in an earlier message I have yet to come across a book or tutorial which does this right. It should treats the language from a practical point of view, with IO, QuickCheck generators, data types, GUI's etc. right up front, rather than avoiding it until chapter 19 and later. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Daniel Fischer wrote: P.S.: In May, there was a 'Daniel Carrera' around, too. Isn't that a strange coincidence? That was myself, using a different email address. I didn't get too far with Haskell that time, but I remembered that I liked it, so I'm going back to it a bit now. But I'm still a newbie :) Notice that I was already familiar with a few, very basic concepts (what is functional programming?) Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/21/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Dienstag, 20. Dezember 2005 20:07 schrieb Sebastian Sylvan: [...] It's sometimes beneficial to lie a bit when starting out. Perhaps say something like this is a simplified view of things, for all the gory details see chapter 19. Monadic IO is pretty darn cool, sadly that means that many tutorial authors are tempted to spend pages upon pages explaining exactly why it's cool and how it works, but that is NOT what most people starting out with the language need to read. I'm still looking for a good *practical* tutorial that I could recommend to newcomers. IO, data types and QuickCheck in the very first chapter, I say! Real program examples from the get go, and go into the theory on why this has been hard in FP before Haskell (or Monadic IO rather) much much later, so as to not scare people away. I think that there are cases where it's better to start with ordinary functional programming and come to I/O later. In my opinion, an example case would be teaching Haskell at a university. Well, I certainly disagree there. I'm not advocating going into a full-blown explanation of monads, just enough to actually be able to write a real stand-alone program after the first chapter. They only need to know that do-notation is for sequencing computations, and (-) is for binding a name to the result of a computation. That's it! You could spend the next ten chapters with coding examples that are not very IO-heavy, and lead with a good example of doing as much as possible in the pure world (as well as pointing out every now and then whenever a particularly good IO-separtion was achieved - to emphasize that it's good practice). When someone who has programmed before learns Haskell and gets the impression that IO is beeing left for later because it's hard they might think bah, what a rubbish language, IO in Visual Basic isn't hard at all!. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/21/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Mittwoch, 21. Dezember 2005 11:48 schrieb Robin Green: [...] If people want Haskell to be treated as a practical language, not just something for doing academic teaching and research with, it should be taught as a practical language - which means that things like IO and space/time usage come to the forefront. So programming is only practical if it's deals with a lot of I/O? This is wrong, in my opinion. Take a compiler. The only I/O it does is some simple file I/O. The important part of the compiler doesn't deal with I/O at all. I'm pretty sure that's not what he was saying. But a practical application need IO. I'm not saying that only applications doing *lots* of IO should be considered practical, I'm saying that any real-world stand-alone application needs *some* IO. Beginners know that too. In fact, they often think that practical applications need far more IO than they really do! So to insinuate even slightly that Haskell is bad at IO by avoiding it for two thirds of a book, is really going to inforce the idea that Haskell isn't a practical language for practical applications. It's easily remedied by teaching them a little IO up front (to show them it's not scary), and then leaving it alone for a while, having a more thorugough treatment of it later on. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Sebastian Sylvan wrote: Well, I certainly disagree there. I'm not advocating going into a full-blown explanation of monads, just enough to actually be able to write a real stand-alone program after the first chapter. They only need to know that do-notation is for sequencing computations, and (-) is for binding a name to the result of a computation. That's it! As a newbie... I agree that a newbie should be able to write this fairly early on: main = do x - getLine() putStrLn (The answer is ++ show(fib(read(x Now, you just said do-notation is for sequencing computations. Would it be fair to say that do-blocks are imperative blocks in an otherwise functional program? You could spend the next ten chapters with coding examples that are not very IO-heavy, and lead with a good example of doing as much as possible in the pure world (as well as pointing out every now and then whenever a particularly good IO-separtion was achieved - to emphasize that it's good practice). When someone who has programmed before learns Haskell and gets the impression that IO is beeing left for later because it's hard they might think bah, what a rubbish language, IO in Visual Basic isn't hard at all!. I would agree with both paragraphs. Show basic IO and show that there's no need for complex IO because all the logic should be functional. Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Sebastian Sylvan wrote: Beginners know that too. In fact, they often think that practical applications need far more IO than they really do! So to insinuate even slightly that Haskell is bad at IO by avoiding it for two thirds of a book, is really going to inforce the idea that Haskell isn't a practical language for practical applications. It's easily remedied by teaching them a little IO up front (to show them it's not scary), and then leaving it alone for a while, having a more thorugough treatment of it later on. You can show them this on the first page: main = do x - getLine() print my_program(x) And spend the next 200 pages showing them all the nifty things and purely functional things that my_program() could do and not mention monads until chapter 14. Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 2005-12-21 at 13:10 +0100, Udo Stenzel wrote: . . . tutorial. Before that, IO should be restricted to the EVA principle (Eingabe, Verarbeitung, Ausgabe == Input, Processing, Output). It was a good principle in the 60s, and it still is. Unless you want to teach people to program as they would do in Basic, that is. Don't forget that the pioneers of IPO (Input,Process,Output) quickly went to HIPO (Hierarchical IPO). My natural design style is top-down, functional decomposition, separation of concerns, all the good things. Many problems involve relatively complex mixtures of IO and processing, which I can capture fairly naturally with programs whose IO is distributed over various nodes low in a functional decomposition tree. It often feels like I'm turning a program inside-out to have the IO monad at the top with pure functional snippets called at various points in a do sequence. And if the only way to express my decomposition tree is with a tree of imperative code inside the IO monad, then I start to ask, Why am I here? I can write this in Scheme or Ocaml. Since I'm a Haskell novice, I'm well aware that I may totally misunderstand the situation. However, I hadn't seen anything in tutorials that would lead me to think so. That said, one of the great effects of these recent threads is that they've alerted me to the fact that apparently the available tutorial information has expanded and been improved since last I looked. So I think I shall now go do some deep browsing; thanks for the links. -- Bill Wood PS: While looking over my post it occurred to me that the issue is at least as much methodological as it is linguistic. So I ask: Does Haskell stand far enough apart from other programming languages to warrant adapting standard methodological principles to it? Is there an identifiable Haskell Way? -- bw ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 12/21/05, Daniel Carrera [EMAIL PROTECTED] wrote: Sebastian Sylvan wrote: Beginners know that too. In fact, they often think that practical applications need far more IO than they really do! So to insinuate even slightly that Haskell is bad at IO by avoiding it for two thirds of a book, is really going to inforce the idea that Haskell isn't a practical language for practical applications. It's easily remedied by teaching them a little IO up front (to show them it's not scary), and then leaving it alone for a while, having a more thorugough treatment of it later on. You can show them this on the first page: main = do x - getLine() print my_program(x) Well, more like main = do x - getLine print (my_program x) But we get the point! :-) -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Am Mittwoch, 21. Dezember 2005 16:30 schrieb Daniel Carrera: [...] Would it be fair to say that do-blocks are imperative blocks in an otherwise functional program? Not really. do expressions are (normally) equivalent to expressions containing applications of (=) and/or (). If the monad you use is IO then a do expression isn't really an imperative block but an expression whose value is a *description* of an imperative block. If the monad you use is not IO then a do expression may have nothing to do with imperative code at all. [...] Cheers, Daniel. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Udo Stenzel wrote: [... re pitfalls of IO for the beginner ] Here's another one: I've heard a fellow claim, Haskell is basically unsuitable to implement a compiler, because Haskell is weak at IO and everything needs IO, the lexer, the preprocessor, the parser, the pretty-printer, ... Can you imagine what convoluted mess he would write if he learned IO first? I wouldn't be too worried. If these things really must be learned in some prescribed order, then we're all doomed - who here learned Haskell as their first programming language? Meanwhile, that fellow evidently didn't write any compiler in Haskell at all. Better a C++ program than a Haskell program that offends you? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Donn Cave wrote: Meanwhile, that fellow evidently didn't write any compiler in Haskell at all. Better a C++ program than a Haskell program that offends you? Oh no, he actually wrote something disgusting built mostly out of regexes in Perl. I don't think it even works, and I don't think I could have convinced him to Do The Right Thing in whatever language. But that's besides the point. The conviction that a parser or lexer or prettyprinter means IO is simply wrong, and imho a tutorial should show how much is purely functionally possible before introducing control flow, mutable variables and all the other ugliness. It's more productive this way. Udo. -- Slous' Contention: If you do a job too well, you'll get stuck with it. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tutorial uploaded
Some example for writing a text the IO oriented way: do putStrLn bla replicateM 5 (putStrLn blub) putStrLn end whereas the lazy way is putStr (unlines ([bla] ++ replicate 5 blub ++ [end])) Um, maybe it's just me, but I think the first program is far superior to the second one. The last thing you want your I/O code to be is lazy. You want the exact opposite: you want it to be as strict as possible. Not only does the second version waste a lot of CPU time and memory for pointlessly constructing a lazily evaluated list nobody ever needs, it will also explode into your face the moment you use that approach to write any non-trivial number of bytes. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, Dec 21, 2005 at 07:35:28PM +0100, Peter Simons wrote: Some example for writing a text the IO oriented way: do putStrLn bla replicateM 5 (putStrLn blub) putStrLn end whereas the lazy way is putStr (unlines ([bla] ++ replicate 5 blub ++ [end])) Um, maybe it's just me, but I think the first program is far superior to the second one. The last thing you want your I/O code to be is lazy. You want the exact opposite: you want it to be as strict as possible. Not only does the second version waste a lot of CPU time and memory for pointlessly constructing a lazily evaluated list nobody ever needs, it will also explode into your face the moment you use that approach to write any non-trivial number of bytes. Isn't it just the usual elegance/efficiency trade-off? Personally, I would prefer the first version, unless it was not efficient enought. Actually this example is a bit too simple to show the benefits and problems of both approaches. Consider using a pretty printing library vs doing the same thing as a sequence of putStr's. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, 21 Dec 2005, Peter Simons wrote: Some example for writing a text the IO oriented way: do putStrLn bla replicateM 5 (putStrLn blub) putStrLn end whereas the lazy way is putStr (unlines ([bla] ++ replicate 5 blub ++ [end])) Um, maybe it's just me, but I think the first program is far superior to the second one. The last thing you want your I/O code to be is lazy. You want the exact opposite: you want it to be as strict as possible. Not only does the second version waste a lot of CPU time and memory for pointlessly constructing a lazily evaluated list nobody ever needs, it will also explode into your face the moment you use that approach to write any non-trivial number of bytes. Surely the actual explosion comes about because PutStr forces the lot at once? If PutStr were to evaluate a character at a time, the laziness would be slow and spew a lot of garbage to collect but not hang on to as much space as you suggest. Not to say that the strict solution isn't still more efficient, of course. -- [EMAIL PROTECTED] The task of the academic is not to scale great intellectual mountains, but to flatten them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wednesday 21 December 2005 18:48, Udo Stenzel wrote: Donn Cave wrote: Meanwhile, that fellow evidently didn't write any compiler in Haskell at all. Better a C++ program than a Haskell program that offends you? Oh no, he actually wrote something disgusting built mostly out of regexes in Perl. I don't think it even works, and I don't think I could have convinced him to Do The Right Thing in whatever language. But that's besides the point. The conviction that a parser or lexer or prettyprinter means IO is simply wrong, and imho a tutorial should show how much is purely functionally possible before introducing control flow, mutable variables and all the other ugliness. It's more productive this way. This is a red herring IMO. A good tutorial on Haskell can mention and explain how to do IO in the first chapter and /still/ show clearly and convincing how to do most of the real work in an elegant, purely functional style. It could even contain a 'bad example' where IO is used unnecessarily and compare it to the 'good' functional version. It is not a good idea to treat beginner's in Haskell as little children who must be protected from the bad world of IO as long as possible. (FWIW, it can be argued that this isn't even a good attitude toward little children.) Especially since most Haskell newcomers will have a background in imperative programming, as someone esle already mentioned. Of course, /precise/ explanation of the IO monad must be postponed to a later chapter, and surely only /after/ introducing monads in general and giving some non-IO examples. I would also argue that the word 'category theory' should /not/ appear in the main text of a tutorial (a small footnote might be acceptable, as well as a reference in a late chapter named 'further reading'). Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wed, Dec 21, 2005 at 09:30:14PM +, Philippa Cowderoy wrote: On Wed, 21 Dec 2005, Tomasz Zielonka wrote: I don't know how it's done, but when you compile it with 'ghc -O2', the program runs in constant space. Unfortunately with Hugs and GHCi it grows. The live set, or just the heap? It depends on what you mean by live set. If it's the conservative approximation as used by GC (reachability from root set), then yes, because it more or less equals heap. If you mean the set of nodes that will be referenced by program in the future, then probably no. You mean the latter, right? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 21/12/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Wed, Dec 21, 2005 at 07:13:07PM +, Philippa Cowderoy wrote: Try running putStrLn (unlines (repeat hello!)) You may be surprised ;-) Or not ;-) But yes, I should've checked and my comments on how that'll behave stand. It would be nice to think something clever could happen regarding memory management as well, but I'm familiar enough with GCed systems by now to be somewhat wary of cleverness. I don't know how it's done, but when you compile it with 'ghc -O2', the program runs in constant space. Unfortunately with Hugs and GHCi it grows. It really shouldn't grow at all, and at least in my short tests in ghci and hugs, it doesn't grow for me. The putStrLn won't force any more of the string than it wants to print at any moment, and afterward, that part of the string is garbage, and should get collected right away. There are two ways to make a Haskell program more efficient: Make it stricter, or make it lazier. What do I mean by the latter? Simply that if you can design each part of your program (as much as possible) to be able to output something only given a small prefix of its input, then you'll often see some really nice efficiency. The pipeline scheduler which I wrote for a summer job made heavy use of this fact, and at a few points in the design/coding, I made ridiculously large performance gains in both memory consumption and runtime simply by making sure that lists and other structures were lazily produced. In the end, the result was a (combinatorially large) list of all the possible schedules for the given input code, in order of algorithm greediness. Taking the head of the list was essentially running the greedy algorithm, but if the greedy solution, say, couldn't be register allocated, the next item in the list could be observed, which would backtrack a bit and find another. In fact, the entire algorithm was designed this way. That's essentially what the list monad gives you, after all. Leaning on laziness can result in very elegant generative algorithms which run quite quickly. Strictness is really only desired when you are trying to collapse something large down into a small summary. That's what things like foldl' are for. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wednesday 21 December 2005 12:17, Daniel Carrera wrote: Robin Green wrote: Whilst localising IO to a small part of the program is generally a good idea, beginners should not be scared off by the thought that IO in Haskell is so hard it has to be covered on page 94. This is not the case. It should be introduced on page 1. As a newbie... I'll agree with Robin. I /did/ think that IO in Haskell was probably very difficult because it's covered in page 94. I skimmed through YAHT and IO is covered wyyy deep into the document. I haven't read that section yet, but there is a lot of content and to me it looked like it must be something difficult. I guess/hope that when I get around to reading it I'll find out that it's not as scary as it looks. Rest assured it is dead simple. Really. I would even argue that it is a lot simpler than in many other languages. The only thing that is strange for beginners is that you cannot /do/ IO from inside a function (because functions in Haskell are pure, period). However you can easily /construct IO-performing actions/ inside functions, since such actions are ordinary (first-class) /data values/. That's what monadic IO is about. IO-actions (=procedures?) are data and can be manipulated like other ordinary data. However, since IO is necessarily an /abstract/ data type, data construction is limited to what's offered by the public interface (which is essentially the type class 'Monad', plus all the 'primitive' actions, i.e. putChar, getChar, openFile, ...). One of the funny aspects of IO in Haskell is that it tends to look like perfectly ordinary imperative programming. That is what the do-Notation (including - 'assignment') is about. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
As a newbie... I'll agree with Robin. I /did/ think that IO in Haskell was probably very difficult because it's covered in page 94. I skimmed through YAHT and IO is covered wyyy deep into the document. I haven't read that section yet, but there is a lot of content and to me it looked like it must be something difficult. I guess/hope that when I get around to reading it I'll find out that it's not as scary as it looks. Rest assured it is dead simple. Really. I would even argue that it is a lot simpler than in many other languages. I agree. It's on page 31 in YAHT, and 1-11 are getting started with Hugs and so on. One of the whole points of YAHT is to introduce it early. -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
noise The truth is, Haskell friggen rocks at IO compared to imperative languages. We are all spoiled and see IO in haskell as ugly because we have been exposed to the pure functional goodness of the rest of haskell. but teaching haskell as a better impertive language than imperative ones from the getgo seems like a very good approach for bringing people over. Just the idea that you can write things like mapM and replicateM is enough to blow the mind of many impertive programmers. They don't need to be forced to learn the pure functional side, they will eventually learn to do so on their own because it is so darn nice. You can't not start with IO for people who already know how to program, if you are teaching someone programming for the very first time then starting with the pure functional side is fine. But for people that already know how to program, they are constantly thinking of everything else they have written and how they might do it in the language they are currently learning comparing and contrasting in their head. They need to have the tools to replicate what they have done with other languages right away, they don't want to know how to do the examples given in the book except insofar as they let them understand how to write the examples wiggling around in their head. /noise John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Wednesday 21 December 2005 16:49, Sebastian Sylvan wrote: On 12/21/05, Daniel Carrera [EMAIL PROTECTED] wrote: Sebastian Sylvan wrote: Beginners know that too. In fact, they often think that practical applications need far more IO than they really do! So to insinuate even slightly that Haskell is bad at IO by avoiding it for two thirds of a book, is really going to inforce the idea that Haskell isn't a practical language for practical applications. It's easily remedied by teaching them a little IO up front (to show them it's not scary), and then leaving it alone for a while, having a more thorugough treatment of it later on. You can show them this on the first page: main = do x - getLine() print my_program(x) Well, more like main = do x - getLine print (my_program x) This: main = do x - getLine print (my_program x) would be correct too. (Just to make it clear that the main point was not the different layout but the parentheses: Haskell uses them only to indicate precedence, they are not required around function arguments.) Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tutorial uploaded
Daniel Carrera wrote: As a newbie... I agree that a newbie should be able to write this fairly early on: main = do x - getLine() putStrLn (The answer is ++ show(fib(read(x I'd agree for some definition of 'early'. I'll elaborate: This entire discussion is about 'breaking a cyclic graph of conceptual dependencies'. Unfortunately, I don't think it can be done well in short amount of time. The above code snippet contains typeclasses (show, read, monadic IO, lists), syntactic sugar (do, -). When you say a 'newbie' should be able to write that early on, I'd interpret that as 'a newbie should be able to regurgitate this early on' because the next thing a newbie might want to do is try to divide the result of fib by a float and wonder why he can't do that, or try to debug his fib implementation by trying to insert a putStrLn. There are numerous ways to frustration unless the newbie is comfortable with typeclasses, monads, etc. This happens all the time when somebody is learning a new language, but it's most problematic for haskell because the breadth of knowledge (of various concept of the language) a learner has to gather before he can dive deep (formulation, compilation, execution, debugging) into an actual (even trivial) program is larger than all popular languages out there. In every language, the most powerful features make their ways into the most basic elements (as they should so that the entire language benefits, but then, lists are monads?!?!). Learners of C++ with a C background are not as much troubled by cout yadda endl; even though there is operator overloading, references and the streams class hieararchy in that statement. You can close your eyes and pretend that cout is just magic and re-visit that node when you are comfortable with classes. I don't think we can break cycles easily like that in Haskell. The mental load is very high, and with concerns about language features vs complexity even in other languages (see http://lambda-the-ultimate.org/node/view/1155) I think we are observing a new phenomenon: languages worth learning from now on will be increasingly difficult (heck, even Perl is difficult now), and we'll have to do away with 'tutorials' mostly. In fact what we have are not really tutorials (YAHT is a small book! compare that with http://www.ocaml-tutorial.org/). I think it's a tall order for a 'tutorial' to teach Haskell (which may be why we end up reading 4-5 of them). In fact Hudak's Haskell book was the first introductory language book I'd ever bought. That's why I think tutorials can have be frustrating and it takes a well edited book and . Cheers, Koray ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tutorial uploaded
== So how do I write Hello, world? == Well, the first thing you need to understand that in a functional language like Haskell, this is a harder question than it seems. Most of the code you will write in Haskell is purely functional, which means that it returns the same thing every time it is run, and has no side effects. Code with side effects is referred to as imperative, and is carefully isolated from functional code in Haskell. I believe this description is a bit misleading. Code written in the IO monad is purely functional just the same. Haskell knows no other code than purely functional one. In my humble opinion, it's unfortunate that many tutorials and introductionary texts leave the impression that monadic code would be something utterly different than normal Haskell code. I feel it intimidates the reader by making a monad appear like black magic, even though it's little more than syntactic sugar to describe implicit function arguments. If we'd have an opaque World type instead of the IO monad, 'putStrLn' would be: putStrLn :: String - World - World How is this function any different from any other function? So why should putStrLn :: String - IO () be different from any other function? Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On 20 Dec 2005 19:52:31 +0100, Peter Simons [EMAIL PROTECTED] wrote: == So how do I write Hello, world? == Well, the first thing you need to understand that in a functional language like Haskell, this is a harder question than it seems. Most of the code you will write in Haskell is purely functional, which means that it returns the same thing every time it is run, and has no side effects. Code with side effects is referred to as imperative, and is carefully isolated from functional code in Haskell. I believe this description is a bit misleading. Code written in the IO monad is purely functional just the same. Haskell knows no other code than purely functional one. In my humble opinion, it's unfortunate that many tutorials and introductionary texts leave the impression that monadic code would be something utterly different than normal Haskell code. I feel it intimidates the reader by making a monad appear like black magic, even though it's little more than syntactic sugar to describe implicit function arguments. If we'd have an opaque World type instead of the IO monad, 'putStrLn' would be: putStrLn :: String - World - World How is this function any different from any other function? So why should putStrLn :: String - IO () be different from any other function? It's sometimes beneficial to lie a bit when starting out. Perhaps say something like this is a simplified view of things, for all the gory details see chapter 19. Monadic IO is pretty darn cool, sadly that means that many tutorial authors are tempted to spend pages upon pages explaining exactly why it's cool and how it works, but that is NOT what most people starting out with the language need to read. I'm still looking for a good *practical* tutorial that I could recommend to newcomers. IO, data types and QuickCheck in the very first chapter, I say! Real program examples from the get go, and go into the theory on why this has been hard in FP before Haskell (or Monadic IO rather) much much later, so as to not scare people away. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Peter Simons wrote: In my humble opinion, it's unfortunate that many tutorials and introductionary texts leave the impression that monadic code would be something utterly different than normal Haskell code. I feel it intimidates the reader by making a monad appear like black magic, even though it's little more than syntactic sugar to describe implicit function arguments. I'm scared of monads :) I really don't know what a monad is. All I know is that you need it for IO because IO implies side-effects and I know that Monad is a very scary-looking word :) If we'd have an opaque World type instead of the IO monad, 'putStrLn' would be: putStrLn :: String - World - World That seems less scary. Cheers, Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/I am not over-weight, I am under-tall. / ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tutorial uploaded
Daniel Carrera writes: I'm scared of monads :) I really don't know what a monad is. Neither do I, but that doesn't mean that I can't use just fine. ;-) putStrLn :: String - World - World That seems less scary. Things become a lot clearer when you think about how to print _two_ lines with that kind of function. You'd write: f :: World - World f world = putStrLn second line (putStrLn first line world) The 'world' parameter forces the two functions into the order you want, because printing second line needs the result of printing first line before it can be evaluated. However, writing complex applications with that kind of API would drive you nuts, so instead you can say f :: IO () f = do putStrLn first line putStrLn second line and it means the exact same thing. Curiously enough, if you check out the reference documentation at: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-ST.html#t%3ARealWorld ..., you'll find that a World type actually exists. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Tue, 2005-12-20 at 20:07 +0100, Sebastian Sylvan wrote: . . . I'm still looking for a good *practical* tutorial that I could recommend to newcomers. IO, data types and QuickCheck in the very first chapter, I say! Real program examples from the get go, and go into the theory on why this has been hard in FP before Haskell (or Monadic IO rather) much much later, so as to not scare people away. I second this motion. I've been interested in Haskell for some time, experimented with it several years ago, and then moved on to other things. That first time around I saw no comprehensible discussions of monadic IO (for example, I thought that the fact that when you're in a monad you can't get out was characteristic of monads in general, not a peculiarity of IO). The state of available knowledge for beginners has clearly improved since I last looked. I applaud this discussion for making Haskell more accessible for the newbie. (Now, if someone would just explain how to get reliable performance information while jumping through only a bounded number of hoops ... :-) -- Bill Wood ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
Hi, Hugs Interpreter onlySuitable for learning. You'll need GHC for serious work. This is putting Hugs down quite a bit. I personally prefer Hugs, and use it for serious work (including developing a Haskell compiler, and 4 years of academic study and counting). About the only thing it doesn't do is produce standalone binaries. I would have actually said Hugs, and especially the Windows front end WinHugs was a lot more suitable for beginners than GHC, but the wiki page very much gives the other impression. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tutorial uploaded
On Tuesday 20 December 2005 20:58, Peter Simons wrote: Daniel Carrera writes: I'm scared of monads :) I really don't know what a monad is. Neither do I, but that doesn't mean that I can't use just fine. ;-) putStrLn :: String - World - World That seems less scary. Things become a lot clearer when you think about how to print _two_ lines with that kind of function. You'd write: f :: World - World f world = putStrLn second line (putStrLn first line world) The 'world' parameter forces the two functions into the order you want, because printing second line needs the result of printing first line before it can be evaluated. However, writing complex applications with that kind of API would drive you nuts, and would also be unsafe without some kind of strong guarantee that each single 'world' value is unique. (This is how they do it in Clean.) Imagine g :: World - World g world = let world' = putStrLn first line world in putStrLn second line world -- oops, forgot the ' so instead you can say f :: IO () f = do putStrLn first line putStrLn second line and it means the exact same thing. /and/ it guarantees that 'world' cannot be accidentally duplicated because it is not directly accessible to the program, thus there is only one 'world' ever existing at the same time, thus all IO actions are cleanly sequenced according to the data dependencies. Curiously enough, if you check out the reference documentation at: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad- ST.html#t%3ARealWorld ..., you'll find that a World type actually exists. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Tutorial uploaded
Hello Neil, Tuesday, December 20, 2005, 11:52:51 PM, you wrote: NM Hi, Hugs Interpreter onlySuitable for learning. You'll need GHC for serious work. NM This is putting Hugs down quite a bit. I personally prefer Hugs, and NM use it for serious work (including developing a Haskell compiler, and NM 4 years of academic study and counting). for me, Hugs and especiall WinHugs is an amazing tool to develop programs that then will be compiled by GHC. they have a greatest level o compatibility while Hugs loads programs 10 times faster than GHCi and have much more helpful environment (especially WinHugs 2005) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
