Hello Wolfgang, Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this discussion:
make a strict Haskell dialect. implement it by translating all expressions of form "f x" into "f $! x" and then going to the standard (lazy) haskell translator. the same for data fields - add to all field definitions "!" in translation process. then add to this strict Haskell language ability to _explicitly_ specify lazy fields and lazy evaluation, for example using this "~" sign
what it will give? ability to use Haskell as powerful strict language, what is especially interesting for "real-world" programmers. i have found myself permanently fighting against the lazyness once i starting to optimize my programs. for the newcomers, it just will reduce learning path - they don't need to know anything about lazyness
WJ> Since laziness often allows you to solve problems so elegantly, I'm really WJ> scared of the idea of a "Strict Haskell"! :-( Is laziness really so "unreal" WJ> that real-world programmers have to see it as an enemy which they have to WJ> fight against? WJ> In fact, I was kind of shocked as I read in Simon Peyton Jones' presentation WJ> "Wearing the hair shirt" [1] that in his opinion "Lazyness doesn't really WJ> matter". i suggest you to write some large program like darcs and try to make it as efficient as C++ ones. i'm doing sort of it, and i selected Haskell primarily because it gives unprecedented combination of power and safety due to its strong but expressive type system, higher-order functions and so on. i also use benefits of lazyness from time to time, and may be even don't recognize each occasion of using lazyness. but when i'm going to optimize my program, when i'm asking myself "why it is slower than C counterparts?", the answer is almost exclusively "because of lazyness". for example, i now wrote I/O library. are you think that i much need lazyness here? no, but that i really need is the highest possible speed, so now i'm fighting against lazyness even more than usual :) well, 80% of any program don't need optimization at all. but when i write remaining 20% or even 5%, i don't want to fight against something that can be easily fixed in systematic way. all other widespread languages have _optional_, explicitly stated lazyness in form of callable blocks, even the Omega goes in this way. and i'm interested in playing with such Haskell dialect in order to see how my programming will change if i need to explicitly specify lazyness when i need it, but have strictness implicitly. i think that newcomers from other languages who wants to implement real projects instead of experimenting will also prefer strict Haskell you may hear that last days Haskell become one of fastest language in the Shootout. why? only because all those programs was rewritten to be strict. it was slow and hard process. and adding preprocessor that makes all code strict automagically will allow to write efficient Haskell programs without reading fat manuals each laguage feature has its time. 15 years ago i could substantially speed up C program by rewriting it in asm. Now the C compilers in most cases generate better code than i can. moreover, strict FP languages now are ready to compete with gcc. But lazy languages are still not compiled so efficient that they can be used for time-critical code. so, if we don't want to wait another 10 years, we should implement easier ways to create strict programs. if you think that lazy programming is great, you can show this in shootout or by showing me the way to optimize code of my real programs. i'm open to new knowledge :) -- Best regards, Bulat mailto:bulatz@HotPOP.com