Nick wrote:
Hi all,
(Another topic stolen from a Russian forum discussion).
As everyone know, there are lot of strict languages, that have
possibilities to "switch on" lazy evaluation when needed.
But the examples that I saw on Haskell, there was not much use of lazy
evaluation, often there were just several lazy points, and the rest
could be done strictly without loss of generality. For example, in
finding primes:
I think the Haskell solution is more compact due to syntactic sugar,
curring and "parentheses-free-ness", *not* lazy evaluation.
Hi,
I think a big advantage is that programs can be written without
regard for whether or not a value will in the long run actually be
evaluated.
For me one of the best examples of this is that of logging within a
compiler.
Consider a compiler which operates roughly as such
compileProgram :: String -> IO ()
compileProgram program =
let (log, abstract) = parse program
(log2, typedProgram) = typeCheck abstract log2
(log3, convertedProgram) = convertToIntermediate typedProgram log2
(log4, convertedToAssembly) = convertToAssembly convertedProgram log3
in do writeFile "a.asm" (show convertedToAssembly)
writeFile "a.log" (show log4)
Now each of the intermediate transforming calls will produce some
logging information which is added to the current log.
Some of these will require quite heavy traversing of the entire program,
which will almost certainly require auxiliary functions.
Suppose we want to allow the suppressing of the log information ie:
compileProgram :: String -> Bool -> IO ()
compileProgram program logOrNot =
let (log, abstract) = parse program
(log2, typedProgram) = typeCheck abstract log2
(log3, convertedProgram) = convertToIntermediate typedProgram log2
(log4, convertedToAssembly) = convertToAssembly convertedProgram log3
in do writeFile "a.asm" (show convertedToAssembly)
if logOrNot
then writeFile "a.log" (show log4)
else return ()
Now if this is a strict language we have to go and modify all the
intermediate functions to first of all take in a boolean and then use
that to decide whether or not to produce any logging information. With a
lazy language though, we don't need to do that, we're already done, no
logging information will be produced if 'logOrNot' is false, because it
will never be forced to evaluate the thunk.
According to one guy's analogy: the Real World is strict - in order to
drink tea, you have to put the cattle on the fire, wait until water
boils, brew tea and then drink. Not the cattle is put on the fire,
water boils and the tea is brewed when you take the empty cup to start
drinking. :-)
Yes true, but you don't just boil up the kettle and brew the tea unless
you have first asked if anyone actually wants tea.
The question is the following: how big the gap between strict
languages with lazy constructs and Haskell? Does the default lazyness
have irrefutable advantage over default strictness?
Thank you for the attention.
With best regards,
Nick.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
