- Haskell - Haskell.org

RE: stack overflow
by Simon Peyton-Jones 26 Feb '01

26 Feb '01

Consider foldl (+) 0 [x1,x2,x3,x4,... This rewrites to foldl (+) (0 + x1) [x2,x3,x4,...] ==> foldl (+) (0 + x1 + x2) [x3,x4,...] ==> foldl (+) (0 + x1 + x2 +x3) [x4,...] And so on. So we build up a giant chain of thunks. Finally we evaluate the giant chain, and that builds up a giant stack. Why can't GHC evaluate as it goes? Because it's only correct to do so if the function is strict in its second argument, which (+) is, and so is addToFM. If GHC were to inline foldl more vigorously, this would happen. Maybe we should make it do so, to avoid gratuitous leaks. Simon | -----Original Message----- | From: Julian Assange [mailto:proff@iq.org] | Sent: 24 February 2001 10:50 | To: haskell(a)haskell.org | Cc: proff(a)iq.org | Subject: stack overflow | | | -- compile with: | -- ghc -i/usr/lib/ghc-4.08.1/imports/data -lHSdata | -fglasgow-exts -O -fglasgow-exts wordfreq.hs -o wordfreq | module Main where | import List | import Char(toLower) | import FiniteMap(fmToList,emptyFM,addToFM,lookupWithDefaultFM) | | main = interact (unlines . pretty . sort . fmToList . | makemap . words . lower) | where | pretty l = [w ++ " " ++ show n | (w,n) <- l] | sort = sortBy (\(_,n0) (_,n1) -> compare n0 n1) | makemap = foldl f emptyFM | where | f fm word = addToFM fm word (n+1) | where | n = lookupWithDefaultFM fm 0 word | lower = map toLower | | | | When used with a 170k input file, makemap suffers from a stack | overflow. foldl should be tail recursive. What's the score? | | Julian | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

Lo mejor de Internet aqu�
by promocionesdosmiluno＠yahoo.es 25 Feb '01

25 Feb '01

Visita esta web http://MundoEspanya.redireccion.com

1 0

stack overflow
by Julian Assange 24 Feb '01

24 Feb '01

-- compile with: -- ghc -i/usr/lib/ghc-4.08.1/imports/data -lHSdata -fglasgow-exts -O -fglasgow-exts wordfreq.hs -o wordfreq module Main where import List import Char(toLower) import FiniteMap(fmToList,emptyFM,addToFM,lookupWithDefaultFM) main = interact (unlines . pretty . sort . fmToList . makemap . words . lower) where pretty l = [w ++ " " ++ show n | (w,n) <- l] sort = sortBy (\(_,n0) (_,n1) -> compare n0 n1) makemap = foldl f emptyFM where f fm word = addToFM fm word (n+1) where n = lookupWithDefaultFM fm 0 word lower = map toLower When used with a 170k input file, makemap suffers from a stack overflow. foldl should be tail recursive. What's the score? Julian

1 0

HDirect Installation Problems
by Steinitz, Dominic J 23 Feb '01

23 Feb '01

I'm trying to install HDirect 0.17 but I'm running into the following problem when I do the make lib step: [dom@lhrtba8fd85 hdirect-0.17]$ make lib make -C lib boot && make -C lib all make[1]: Entering directory `/home/dom/hdirect-0.17/lib' /usr/bin/ghc-4.08.1 -M -optdep-f -optdep.depend -optdep-o -optdepo -stat ic -fglasgow-exts -fno-prune-tydecls -recomp -fvia-C Pointer.lhs HDirect.lhs Poi nterPrim.hs Com.lhs Automation.lhs AutoPrim.hs ComPrim.hs StdTypes.hs SafeArray. hs ComException.lhs TypeLib.hs Connection.hs ComDll.lhs ComServ.lhs ClassFactory .lhs StdDispatch.lhs ConnectionPoint.lhs EnumInterface.lhs ExeServer.lhs make[1]: Leaving directory `/home/dom/hdirect-0.17/lib' make[1]: Entering directory `/home/dom/hdirect-0.17/lib' gcc -I. -mno-cygwin -I. -c PointerSrc.c -o PointerSrc.o cc1: Invalid option `no-cygwin' make[1]: *** [PointerSrc.o] Error 1 make[1]: Leaving directory `/home/dom/hdirect-0.17/lib' make: *** [lib] Error 2 Can anyone help? Thanks, Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: unliftM
by Ashley Yakeley 23 Feb '01

23 Feb '01

At 2001-02-22 20:54, Julian Assange wrote: >Is there a standard construct for something of this ilk: > >unliftM :: Monad m a -> a Assuming you mean "unliftM :: (Monad m) => m a -> a", I certainly hope not!!! >In this case, I need to construct a localised stateful computation > >comp :: Int -> Int >comp n = unliftM (do x <- ... return x) The correct way to express this is: comp :: Int -> IO Int comp n = (do x <- ... return x) I think of "IO Int" meaning "instructions for an imperative action, that, if performed, would return an Int". That's quite different from an Int. -- Ashley Yakeley, Seattle WA Almost empty page: <http://semantic.org/>

1 0

unliftM
by Julian Assange 23 Feb '01

23 Feb '01

Is there a standard construct for something of this ilk: unliftM :: Monad m a -> a In this case, I need to construct a localised stateful computation comp :: Int -> Int comp n = unliftM (do x <- ... return x) -- Julian Assange |If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and proff(a)iq.org |work, but rather teach them to long for the endless proff(a)gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery

1 0

RE: A GUI toolkit looking for a friend
by Simon Peyton-Jones 22 Feb '01

22 Feb '01

| What's wrong with "ambitious" high-level systems. Is something amiss | with their basic ideas or is it the nuts and bolts? Are they | too slow? | Too big? Too abstract? In short, why is there a need to | avoid the high | level and go for "in-the-middle" systems? I am still so new | to Haskell | that I have no opinion in the matter, and if Simon's comments reflect | some hard learned lessons about GUIs, I am curious to know what they | are. Nothing's wrong with ambitious systems! But there's an ambition/pragmatism tradeoff. If there was a consensus about the Right Way to build an ambitious (more declarative) system then we could all go for it. But there isn't. So let the experiments flourish, but meanwhile it would be of practical use to many people to have a stable, portable (if less sexy) platform on which to build applications. Simon

3 2

Re:Inferring from context declarations
by George Russell 22 Feb '01

22 Feb '01

Marcin 'Qrczak' Kowalczyk wrote: [snip] > It would require to keep bodies of all polymorphic functions in > a form allowing instantiation in different modules. For example > ghc already requires too much memory (even a hundred MB for large > modules), and it leads to code bloat, so in the current state of > technology it's not advisable to always compile out polymorphism. [snip] I'll bet Marcin a pint (if he wants) that in 10 years time you will need 1GB of virtual memory just to run the latest version of Windows out of the box. How Microsoft will manage to use all that memory, I don't know (will we have irritating pop-up windows showing videos of wizards telling us how to save Explorer settings?), but then 10 years ago I would have found it difficult to conceive of a desktop computer needing 64MB. The current GHC separate compilation strategy probably is advisable at the current time, given available constraints, but I don't think we should make language decisions on that basis.

1 0

Re: Inferring from context declarations
by Lennart Augustsson 22 Feb '01

22 Feb '01

> Simon Peyton Jones' comments about dictionary passing are a red herring, > since they assume a particular form of compiler. Various (MLj, MLton) > ML compilers already inline out all polymorphism. ML is a language where you can do this. In Haskell it is not always possible to eliminate all polymorphism (due to polymorphic recursion). -- Lennart

4 3

RE: putStr vs. putStrLn
by Reuben Thomas 22 Feb '01

22 Feb '01

I just tried this example with putStrLn and putStr, and both worked fine. I am using the latest 4.08.2 GHC under Windows 2000. -----Original Message----- From: Andre W B Furtado [mailto:aw@free.elogica.com.br] Sent: Monday, February 19, 2001 6:20 PM To: Haskell(a)haskell.org Cc: alms(a)cin.ufpe.br; jeaf(a)cin.ufpe.br Subject: putStr vs. putStrLn Hello there. I used the code below to read and print the bitmap file attached (bitmap.bmp), which contains the character ASCII 26 (or 1A-hexa). This special character is used by MSDOS as an end of file marker. import IO import IOExts main :: IO () main = do bmFile <- openFileEx "bitmap.bmp" (BinaryMode ReadMode) charloop bmFile 0 charloop :: Handle -> Integer -> IO () charloop bmFile 70 = hClose bmFile charloop bmFile n = do hSeek bmFile AbsoluteSeek n a <- hGetChar bmFile putStrLn [a] charloop bmFile (n+1) This program did not stuck after reading the special character, but if you change putStrLn by putStr you will notice that a strange thing happens: after reading the special character, the program won't show any more characters. Why does it happen?

1 0