[EMAIL PROTECTED] wrote:
> When I compile the following program with -O -prof using ghc-2.05 on
> a 686 linux box :
>
> module Main ( main ) where
>
> f :: Int
> f = length [1..1000000]
>
> main = print (f + f + f + f)
>
> I get :
>
> Main.o(.text+0x9c): undefined reference to `PrelBase_Z36g3J_fast3'
The examples compiles and links fine here. Perhaps you should try our
latest binary snapshot:
ftp://ftp.informatik.uni-muenchen.de/local/pms/ghc-2.05-all-i386-unknown-linux.tar.gz
[End of advertising :-]
> I am trying to determine to what extent ghc approximates full laziness
> - if I profile without optimisation that is not an accurate
> indication. I don't think any higher-order language can be fully
> lazy, since sometimes evaluation of higher-order functions would lead
> to a sub-expression identical to one that had already been evaluated
> and the system would have no way to know this (trying to detect it
> would seem akin to higher-order unification).
I'm not quite sure if I understood your point, but it sounds a little
bit like the hope "fully lazy" = "fully memoized".
> I hope that, apart from this caveat, ghc is fully lazy, but hope is not
> a sufficient basis for writing programs. The presence or absence of
> laziness could alter the order of an algorithm.
Quite true. But the program above is not an adequate test for full
laziness: f is a constant applicative form (a "normal" programmer would
simply call it a constant, calculated at runtime), so length [1..1000000]
is calculated only once.
> The program below compiles and links with -O -prof, but seg-faults
> during execution (it is fine with just -prof) :
> [ code deleted ]
Works fine here, too. A remark: foo uses take/drop to split a long list.
My wild guess is that there could be a space leak here and you're
measuring mainly GC. It's not that easy to design a non-trivial
long-running Haskell program using lists without introducing space leaks...
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED] D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
