strict Haskell dialect

[Bulat Ziganshin]

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 at HotPOP.com