Unfortunately I think I have to take issue with this statement :).
Therefore, don't worry about this point. A haskell-user doesn't need to know the details of the haskell compiler ins and outs.
I think that at the beginning, a huser doesn't need to know the ins and outs, but from personal experience, the more complicated your programs become, and the more you begin worrying about speed, the more you need to know about the compiler. Personally, I find this quite aggrevating and I think it is one of the least often expressed disadvantages to Haskell. I can see arguments against me immediately, so I'll save you time. For instance, you could argue that it is easier to get "up and running" (well, more like walking in Haskell) in Haskell than say C. I would probably agree. But lets say it comes time to fine tune my program. In C I have (admittedly made up example, but see my recent post the the mailing list on this subject): void sumProdTo(int n, int*s, int*p) { int sum = 0; int i; for (i = 1; i <= n; i++) sum += i; &s = sum; int prod = 1; for (i = 2; i <= n; i++) prod *= i; &p = prod; } and in Haskell: sumProdTo n = (sumTo n, prodTo n) where sumTo 1 = 1 sumTo n = n + sumTo (n-1) prodTo... etc. Now, I want to optimize. In C, I can fuse the loops so I'm only traversing once, which would give me moderate speed improcement. In Haskell, I could also "fuse" the loops and say: sumProdTo 1 = (1,1) sumProdTo n = (n+s,n*p) where (s,p) = sumProdTo (n-1) but this is actually *slower* but there's no way for me to know this without actually running it. in fact, in the discussion about this on the list, no one was really able to give a definitive answer as to why. there was a lot of handwaving about pointers to the heap to pointers to other things, and obviously it has to do with boxing and unboxing and stuff like that, but I think this is a problem. i'm not sure what the moral is. obviously, each of these, in theory, could have equal speed given a good enough optimizing compiler (and, perhaps, no issues of undecidability). however, since in C it's much more clear exactly what is happeneing, you know when you write your code that one thing is going to be faster than another (except when you get to uber complex things when you're worrying about cache sizes, etc, but that's out of the scope of this -- you could never even try to worry about something like that in haskell). i think the only real solution would be to put up a web page or something that contains things like "this looks like it would speed up your program but it will actually slow it down." or at least some better tips on getting your programs to run quickly. okay, i'm done. that's not to discourage the original poster to learn haskell - i use it almost exclusively; it's just that i don't think it's fair to say you don't have to understand what the compiler is doing to write code. - hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 28 Feb 2002, Rijk J. C. van Haaften wrote:
Jerry wrote
However, my problems are: * I still don't understand most of the codes I found, like the various haskell libraries Practice is the only answer to this problem, as Keith Wansbrough says.
* I still have no clue of most (ok, almost all) of what is being discussed in this mailing list Though I am a CS student, being highly interested in Haskell and practising a lot, I didn't understand most of the discussions on this mailing list. I started understanding them only after I got involved in implementing a Haskell compiler.
Rijk-Jan van Haaften
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe