- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] IPv6?
by Simon Marlow 08 Oct '04

08 Oct '04

On 07 October 2004 21:43, John Goerzen wrote: > Network.Socket in GHC6 seems to be restricted to IPv4, despite the > prsence of AF_INET6. How do I support IPv6 in Haskell? You write some code to handle IPv6 and send it to us for inclusion in Network.Socket ;-) Cheers, Simon

2 1

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

>lists doubly-linked and circular. Erm, this just increases overhead, and file access is linear anyway. Singly linked is good enough. What would make a difference is if each 'node' in the listwas allowed to be larger that '1' item. For example reading a file with 4k buffers, would work much better if the list were represented by 4k chunks in a liked list. Keean.

1 0

RE: [Haskell-cafe] more shootout madness -- hashes in GHC
by Simon Marlow 08 Oct '04

08 Oct '04

On 07 October 2004 20:53, Robert wrote: > I've been playing around with the "Hashes, Part II" code from the > shootout. I wanted to try to implement this test using Data.HashTable > instead of Data.FiniteMap to see if that would buy us anything. In > fact, the HashTable implementation is consistantly faster than > FiniteMap, but not by a lot (thus making the transition to the IO > monad not worthwhile IMO). The interesting thing, however, is that > at a certain number of iterations (106 in my case), the Hashtable code > segfaults. GDB shows that it is blowing the top off the program stack > and dying when it tries to write to kernel space. (can't write to > 0xbfffffff). Thanks, that's a good bug to catch just before the 6.2.2 release. There is a performance bug in the 6.2.2 HashTable implementation which we already found, but I forgot to merge into the 6.2 branch. The performance bug caused the table to overflow, leading to the segfault (not checking for overflow is another bug). Upshot: this will be fixed in 6.2.2. Furthermore, performance will be better. Cheers, Simon

1 0

Re: [Haskell-cafe] The State Monad
by J.Garrett.Morris＠Dartmouth.EDU 08 Oct '04

08 Oct '04

--- John Goerzen wrote: tick :: Int -> State Int Int tick newval = do put newval return newval Or this: tick :: State Int Int tick = do n <- get return n That is even more incomprehensible to me -- why would removing a line before the return cause a type error? --- end of quote --- I can run both of those without a problem - could you post more of your code? It's probably somewhere else. /gXm

2 1

IPv6?
by John Goerzen 08 Oct '04

08 Oct '04

Hi, Network.Socket in GHC6 seems to be restricted to IPv4, despite the prsence of AF_INET6. How do I support IPv6 in Haskell?

1 0

more shootout madness -- hashes in GHC
by Robert 08 Oct '04

08 Oct '04

I've been playing around with the "Hashes, Part II" code from the shootout. I wanted to try to implement this test using Data.HashTable instead of Data.FiniteMap to see if that would buy us anything. In fact, the HashTable implementation is consistantly faster than FiniteMap, but not by a lot (thus making the transition to the IO monad not worthwhile IMO). The interesting thing, however, is that at a certain number of iterations (106 in my case), the Hashtable code segfaults. GDB shows that it is blowing the top off the program stack and dying when it tries to write to kernel space. (can't write to 0xbfffffff). My question is, why does this happen? Is it well known that sequence_ ing longish lists has this effect? It seems to me that there is no reason to consume stack for sequences of IO like this (especially using sequence_ or >> where we ONLY care about the side effects of the operation). I don't have a stong grasp of how the RTS works, perhaps someone could explain in small words? The code in question is attached. As you can see, I've tried several approaches to reduce the program stack usage, but they seem to generate very similar code. -- Robert robdockins(a)fastmail.fm

1 0

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

I thought that you could use chained buffers to implement the lazy lists, that way the top level interface would still be simple. Also there should be an easy graph-rewrite operation that turns your 3 sequential operations (in the wc example) into 3 parallel ones... put these two together in the compiler and the simple coding should perform near to the complex form. Keean.

1 0

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

results Okay... read the license, seems whoever wrote that article on Clean didn't read the license... You can use it under LGPL, for commercial purposes... Still cant help thinking its yet-another-lazy-functional language - I thought the whole point of Haskell was to stop prolifertion of many non-standard lazy functional languages... (have to say I like the idea of basing the formal semantics on graph rewriting though...) # Keean.

1 0

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

what about, quote: N.B. CleanLanguage is only available under a restrictive license. It's LGPL so long as you're not selling anything you write. Otherwise you have to purchase a commercial license. This probably means CleanLanguage will not survive long. Keean.

1 0

RE: [Haskell-cafe] What Functions are Standard?
by Simon Peyton-Jones 07 Oct '04

07 Oct '04

John | > I have been writing code using the docs over at | > http://www.haskell.org/ghc/docs/latest/html/libraries/index.html, which | > is the only comprehensive library reference I could find. | > | > I am using some code from System.IO, supposedly from base. When I try | > to build this with nhc98, it doesn't know about hGetBuf, hPutBuf, or | > openBinaryFile from there or about mallocForeignPtrArray from the | > Foreign.* area. But all these look standard to me. This is the GHC library documentation, but Hugs and NHC use the same source-code repository, but omitting some functionality. What's omitted is explicitly documented, at the exact link you give above, under "Implementation-specific notes". The language definition for Haskell 98 defines a small collection of libraries, standardised a long time ago. But all implementations come with a much richer set of libraries, many of which are written in Haskell 98, and almost all of which are usable by Haskell 98 programs. These are the ones documented above. Meanwhile lots of people are writing libraries too. In particular, there are several libraries around for reading and writing binary files, and a long recent email thread on the subject. What I'm hoping is that someone, or a small group, will decide on a good interface (in the light of experience thus far) and implement it, so that the rest of us don't have to choose. Simon

1 0