¥X°â¶Ç¯u¸¹½X
¶Ç¯u¸¹½X¥X°â §Ú¦³¥_°Ï02_¶}ÀY¶Ç¯u¸¹½X¡A¦@¬°77270µ§ ¬O§Ú±q¦UÓ¦P·~¤½·|¡B¹q¸Üï¡B¶À¶¡B¼x«H©Ò¡B ºô»Úºô¸ô¡A¥úºÐ¤ù...µ¥µ¥¡A ¸g¦~²Ö¤ë¤@µ§¤@µ§¥´¤J¦¬¶°¤U¨Óªº¡A¶O¤F«Ü¤jªº¥\¤Ò¡C ¥úªá¿ú¶R¼x«H©Ò¥Xªºªº¥U¤l¡A´Nªá¤F¤£¤Ö¿ú¡A ¦A¸g¹L²Îp¤èªk¾ã²z¡A©Ò¥H¨S¦³¥ô¦ó¤@µ§¬O«½Æªº¡A ¨Ã¸g¹L¹ê»Úµo°e´ú¸Õ¡A¦Aç°£±¼µL®Äªº¸¹½X¡A ©Ò¥H¨C¤@µ§¨ì6¤ë©³¬°¤î¡A³£¥i¥Hµo°e¡C ®Ú¾Ú¸gÅç¡A´X¥G©Ò¦³02_¶}ÀYªº¶Ç¯u¡A ³£¤w¦¬¶°¦b³o¸Ì¤F¡A±q¨ä¥L¨Ó·½¡A¤]¤£¤Ó®e©ö¦A§ä¨ì·sªº¡C ¦pªG±z¦³¿³½ìÁʶR¡A§ÚÄ@·N¥H3000¤¸¤À¨É¡C ¾H¤p©j tel: 02-27039827 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: interpreter features
Eray Ozkural (exa) [EMAIL PROTECTED] wrote, On Friday 02 November 2001 10:11, Manuel M. T. Chakravarty wrote: Definitely. An environment like this is pretty trivial todo in Emacs. In fact, the Emacs Haskell mode does most of that already anyway. Well, I use emacs, but didn't really got that working with GHCi. It did work with hugs though. The latest version of http://www.haskell.org/haskell-mode/ has GHCi support. Cheers, Manuel ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
penalty for proper tail recursion
What is the penalty that compilers pay these days for allowing
proper tail-recursion (that does not grow the stack)?
It used to be that implementations targetting C would use
the
while (1) {cont=(*cont)();}
trick, which would lose a factor of 2 or so in speed IIRC.
If the compiler generates native code, then the penalty I believe
consists mainly of the opportunity cost of not targetting C and thus
not being able to piggyback on GCC development efforts, but there may be
costs which I'm failing to visualize from the fact that the hardware is
specialized to handle the conventional way of iterating (ie, structured
looping constructs).
Please share answers for other languages like Mercury, even
though some might think it slightly off-topic...
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
readFile
Hello all. It's me again :) This time I'd like to ask someone to explain me why this happens. I have this piece of code: test = do writeFile /tmp/hsout first h - readFile /tmp/hsout writeFile /tmp/hsout second putStr h So, when i've done this i thought that (putStr h) would print the string first. But it didn't, it printed the string second. My question is why? And how can i do to print the first string instead of the first one. Thank you, João geek code inside :: powered by linux ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Space faults in HaXml
Last week, Dmitry Astapov posted a message to haskell-cafe describing a HaXml program that was running out of memory on large inputs. I've done some investigation on this; here's what I've discovered so far: + The HaXml parser is overly eager; it doesn't produce a value until the entire input has been read. The heap profile for Dmitry's program shows heap usage climbing steadily up to a large peak as the document is being parsed, then a sharp drop as output begins, then climbs again as the output is produced. I suspect that this behaviour is typical of most HaXml programs. I replaced the parser with HXML (recently announced here); this flattens out the first peak, but the second one persists. (HXML uses an incremental parser -- instead of parsing a Document, it parses individual Events (start-tag, character data, end-tag, et cetera) and assembles them into a tree with a separate function.) + nhc98's heap profiler is fantastic. + Under nhc98 (v1.10), 'putStr' doesn't seem to like overly-long strings. This leads to trouble since the HaXml main driver uses a single call to 'hPutStrLn' to write the entire output document. Replacing this with 'mapM_ putChar' (or using GHC 5.02), fixes this problem, but the program still leaks. + The nhc98 heap profiler is amazingly useful. + HaXml uses the Hughes Peyton Jones Pretty printer to format the output. This appears to have a slow leak. (Later tests show that the peak consists of void heap cells from the Pretty module, mostly suspended calls to Prelude.Int- and Prelude.Int+.) Figuring that it's overkill anyway I replaced it with a simpler serializer. + After this change there's *still* a space fault, which with the help of nhc's profiler (which, BTW, is great), I tracked down to the HaXml 'cat' combinator: cat :: [a - [b]] - (a - [b]) cat fs = \e - concat [f e | f - fs] Earlier I had reported that rewriting Dmitry's test case to use the HXML internal representation directly instead of converting to HaXml's representation fixed the space leak. As it turns out, I didn't implement the 'cat' combinator, but instead used a binary concatenation operator: (+++) :: (a - [b]) - (a - [b]) - (a - [b]) f +++ g = \x - f x ++ g x and my implementation of mkElem had the signature mkElem :: String - CFilter - CFilter instead of HaXml's mkElem :: String - [CFilter] - CFilter. which uses 'cat' to process the second argument. Backporting this to HaXml: mkElem' name cf = \x - [CElem (Elem h [] (cf x))] and modifying Dmitry's test case to use mkElem' and +++ instead of mkElem and cat finally fixes the problem. I'm still not sure *why* this does the trick -- hopefully somebody smarter can explain that -- but the modified program runs in bounded space, no matter how large the input file is. (It even works in Hugs, which I found surprising, since the HXML tree builder has a known problem when run with Hugs' garbage collector.) --Joe English [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC version 5.02.1 is released
Julian Seward (Intl Vendor) [EMAIL PROTECTED] wrote, GHC 5.02.1 is available. Currently the source, x86-linux and sparc-solaris tarballs are available. We hope to add binary builds for Win32 and Alpha early next week. -- J There are now binary RPM packages for x86/Linux built with RedHat 7.1 (for glibc 2.2): ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02.1-1.i386.rpm The ghc-prof package contains optional libraries for profiling and the ghc-doc package contains optional documentation. The preformatted documentation is also available online from the GHC Web page. The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02.1-1.src.rpm Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Using the std libraries in Ghc(i)
How can I use the std functions (listed in the 'Standard Libraries for Haskell 98' documentation) in ghc(i)? I've read the ghc documentation, and seen the several categories (which can be added with '-package category_name') available, but I still don't know how to access functions like unfoldr, transpose etc... Thanks in advance, J.A. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Using the std libraries in Ghc(i)
Hello! On Sun, Nov 04, 2001 at 05:00:41PM +, Jorge Adriano wrote: How can I use the std functions (listed in the 'Standard Libraries for Haskell 98' documentation) in ghc(i)? I've read the ghc documentation, and seen the several categories (which can be added with '-package category_name') available, but I still don't know how to access functions like unfoldr, transpose etc... Just import the functions. Those -package things are for GHC's *extra* packages which are beyond the scope of the Standard. Kind regards, Hannah. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
