A while ago I tested all the current haskell implementations
(GHC,HBC,NHC,Hugs) to see which were fully lazy, and it
appeared none of them were. The test I used was as follows:
\begin{code}
import System
main = do
~[arg] <- getArgs
mapM print (func (read arg))
return ()
func n = map (func' n) [1..10]
func' x y = nfib x
nfib 0 = 1
nfib 1 = 1
nfib x = nfib (x-1) + nfib (x-2)
\end{code}
If we call the resulting program with an argument of say 25,
then a fully lazy implementation will take a while computing
the first output and then produce the rest immediately,
a lazy implementation will take just as long to produce each
line of output.
In view of Simon Marlow's comment below, I tried modifying
func' so that it's lambdas weren't adjacent as so:
\begin{code}
func n = map (snd $ func' n) [1..10]
func' x = ((),\y->nfib x)
\end{code}
But I got the same results, I'm using GHC 3.02pl0, if
that's significant.
I also tried out all the same tests but with natural numbers
represented with data constructors (Zero, Succ) in case there
was some funny optimization perculiar to numbers, but I got
the same results again. I was just about to write in my
thesis that current functional languages weren't fully lazy.
Would this be an over simplification of the issue, are there some
options I can pass that make any of the Haskell implementations
fully lazy?
cheers,
Mike
Simon Marlow wrote:
> > I think that the transformation is exactly fully laziness.
> > Sometimes, it
> > helps to improve space/time performance, but it needs to be tunned up
> > due to the reasons including one given by Tweed.
>
> GHC does full laziness(*). As far as I know, no-one ever complained :)
>
> Simon
>
> (*) Well, actually it's nearly-full-laziness, since we tend not to separate
> adjacent lambdas if possible.
