- Haskell-Cafe - Haskell.org

Monad strictness
by Yitzchak Gale 21 Nov '05

21 Nov '05

In the following, why does testA work and testB diverge? Where is the strictness coming from? Thanks, Yitz module Test where import Control.Monad.State import Control.Monad.Identity repeatM :: Monad m => m a -> m [a] repeatM = sequence . repeat testA = take 5 $ flip evalState [1..10] $ repeatM $ do x <- gets head modify tail return x testB = take 5 $ runIdentity $ flip evalStateT [1..10] $ repeatM $ do x <- gets head modify tail return x

3 2

RE: [Haskell-cafe] Project postmortem
by Simon Peyton-Jones 21 Nov '05

21 Nov '05

If it's MacOS specific, we're not going to be much help at GHC HQ, because we don't have any (Macs that is). Wolfgang Thaller is the MacOS expert, but maybe there are others now? Simon | -----Original Message----- | From: Joel Reymont [mailto:joelr1@gmail.com] | Sent: 19 November 2005 00:57 | To: Simon Marlow | Cc: Simon Peyton-Jones; Haskell Cafe | Subject: Re: [Haskell-cafe] Project postmortem | | I'm happy to report that the problem can be reproduced by running the | code from my darcs repo at http://test.wagerlabs.com/postmortem. See | the README file. I'm on Mac OSX 10.4.3. | | The server just sits there, goes through the SSL handshake and... | does nothing else. The clients go through the handshake with the | server and do nothing else. The handshake goes through X number of | times and then the client crashes. | | On Nov 18, 2005, at 1:55 PM, Simon Marlow wrote: | | > How we normally proceed for a crash like this is as follows: examine | > where the crash happened and determine whether it is a result of | > heap or | > stack corruption, and then attempt to trace backwards to find out | > where | > the corruption originated from. Tracing backwards means running the | > program from the beginning again, so it's essential to have a | > reproducible example. Without reproducibility, we have to use a | > combination of debugging printfs and staring really hard at the code, | > which is much more time consuming (and still requires being able to | > run | > the program to make it crash with debugging output turned on).

2 2

RE: [Haskell-cafe] Records
by Simon Marlow 21 Nov '05

21 Nov '05

On 19 November 2005 20:53, Ketil Malde wrote: > Antti-Juhani Kaijanaho wrote: > >> Ketil Malde wrote: >> [about A.b and A . b potentially meaning different things:] >> >> >>> Syntax that changes depending on spacing is my number >>> one gripe with the Haskell syntax >>> >>> >> >> I've generally considered that one of the good ideas in most current >> languages (it's not specific to Haskell). ISTR there was a Basic >> dialect where IFX=0THENX=X+1 >> and >> IF X = 0 THEN X = X + 1 >> meant the same thing. >> >> > My point is that e.g. currently "foo? bar", "foo ?bar" and "foo ? bar" > have (at least two) different meanings. Hierarchical naming collides > with function composition (admittedly only rarely in practice). > Template haskell collides with list comprehensions. > > Do you really think that is such a great idea? I think many people agree that this is a bad thing. It occurs in two places in Haskell 98, I believe: - qualified identifiers (M.T is different from M . T) - single-line comments (--??? is not a comment, but -- ??? is) Both of these were late additions to Haskell, and if we were starting from scratch the syntax would probably not have such anomalies. The other odd cases that GHC has are all extensions too - you mentioned implicit parameters and template haskell, there is also GHC's unboxed values (1#, (#..#)), arrows, and parrays. I would argue against adding any of these syntactic anomalies to the standard language, and we should strive to remove those that we have (e.g. by deprecating the use of '.' as function composition in favour of something else, thus freeing it up for use as record/module selection). I'm assuming you don't consider the distinction between '::' and ': :' to be a problem - the justification for this is simple and logical: a double colon '::' is a reserved symbol, in the same way that 'then' is a reserved identifier. Cheers, Simon

3 2

Two questions: lazy evaluation and Church-Rosser
by Gregory Woodhouse 20 Nov '05

20 Nov '05

This is surely a dumb question, but where can I find a proof of the Church-Rosser theorem? Now, a totally(?) separate question: I've been trying to do some background reading on lambda calculus, and have found discussions of strict evaluation strategies (call-by-value and call-by-name) but have yet to find an appropriate framework for modeling lazy evaluation (much less infinite lists and comprehensions). Can anyone point me in the right direction? === Gregory Woodhouse gregory.woodhouse(a)sbcglobal.net "Nothing is as powerful than an idea whose time has come." -- Victor Hugo

2 1

Formalizing lazy lists?
by Greg Woodhouse 19 Nov '05

19 Nov '05

Maybe this is old hat, but the question about detecting loops in data structures got me thinking about this. I know you can encode the cons operator (and ordinary lists) in pure lambda calculus, but how could you possibly represent something like [0, 1..]? One thought that occurss to me is to treat it ass a kind of direct limit, but of course, the essence of a structure like this is that the ith entry is computable in a natural way, and it seems that an algebraic limit couldn't really capture this intuition unless we were to introduce some sort of higher order structure (which may be what we want, anyway). === Gregory Woodhouse <gregory.woodhouse(a)sbcglobal.net> "Interaction is the mind-body problem of computing." --Philip Wadler

2 7

RE: [Haskell-cafe] Project postmortem
by Simon Marlow 19 Nov '05

19 Nov '05

On 18 November 2005 10:48, Joel Reymont wrote: > On Nov 18, 2005, at 10:17 AM, Simon Peyton-Jones wrote: > >> I hope you don't abandon Haskell altogether. Without steady, >> friendly pressure from applications-end folk like you, things won't >> improve. > > Nah, I'm just having a very frustrating Friday. I think I need some > direction in which to dig and a bit of patience over the weekend. For > example, > > What does this mean precisely? My take is that the GHC runtime is > trying to call a C function. this much I gathered from the source > code. It also seems that since I do not see another library at #0 > then the issue is within GHC. Is that the right take on it? The stack trace doesn't mean much at all I'm afraid - GHC doesn't use the C stack, so any stack trace generated for a crash inside the Haskell code is mostly useless. It does tell you the block in which the crash happened (s8j1_info), and it tells you that the crash was in Haskell and not C. The rest of the frames on the stack are from the GHC runtime, and you'll pretty much always see these same frames on the stack for any crash inside Haskell code. How we normally proceed for a crash like this is as follows: examine where the crash happened and determine whether it is a result of heap or stack corruption, and then attempt to trace backwards to find out where the corruption originated from. Tracing backwards means running the program from the beginning again, so it's essential to have a reproducible example. Without reproducibility, we have to use a combination of debugging printfs and staring really hard at the code, which is much more time consuming (and still requires being able to run the program to make it crash with debugging output turned on). You can get debugging output by compiling your program with -debug, and then running it with some of the -D<something> options (use +RTS -? for a list, +RTS -Ds is a good one to start with). Cheers, Simon

2 2

Records (was Re: [Haskell] Improvements to GHC)
by Dimitry Golubovsky 19 Nov '05

19 Nov '05

Sebastian Sylvan wrote: >Personally I think that the dot is way to good of a symbol to be >"wasted" on function composition. I mean, how often do you really use >function composition in a way which doesn't obfuscate your code? I use >($) way more often than (.). Some people do use it more often than I I found it useful to use (mainly for debugging purposes) mapM (putStrLn . show) <some list> if I want to print its elements each on a new line. -- Dimitry Golubovsky Anywhere on the Web

5 6

Re: [Haskell-cafe] Project postmortem
by Joel Reymont 19 Nov '05

19 Nov '05

The exception is actually from withTimeOut. Removing calls to that lets the handshake proceed. The server is using a client handshake, though, so the handshake of client vs. client goes on indefinitely. I'm fixing the server side and once that is done will clean up SSL at the end of the handshake and launch a few thousand clients. It's not a good repro case yet although I would love to know why withTimeOut is throwing that exception. Joel On Nov 18, 2005, at 5:02 PM, Christian Maeder wrote: > Sorry, I can only show you my output on > Linux turing 2.6.11.4-21.9, but I don't know what's going on and > will not have more time this week. > > Cheers Christian > > maeder@turing:/local/maeder/haskell/postmortem> ./server > 17:55:14: ThreadId 1: Accepted new connection: {handle: <socket: 4>} > 17:55:14: ThreadId 1: Verify locations: 1 > 17:55:14: ThreadId 1: sslGetError: 2 > 17:55:14: ThreadId 4: Starting SSL handshake... > 17:55:14: ThreadId 4: Reading from BIO... > 17:55:14: ThreadId 4: Waiting for BIO 0x080d10d8 > 17:55:14: ThreadId 4: waitForBio: gotta wait a bit... > server: unknown exception -- http://wagerlabs.com/

1 0

RE: [Haskell-cafe] Project postmortem
by Simon Peyton-Jones 19 Nov '05

19 Nov '05

| Unless lightning strikes and tomorrow morning I figure out what's the | deal with the spurious Mac OSX crashes, I think this might be my last | network app in Haskell. I should really be spending time on the | business end of the app intead of figuring out platform differences | and the like. Joel, I think it's fantastic that you've been pushing on Haskell in the way you have. What I learn from your experience is that the *language* is pretty good for what you wanted to do (esp lightweight concurrency) but the *libraries* in the area of networking are lacking both functionality and (more particularly) robustness. I hope you don't abandon Haskell altogether. Without steady, friendly pressure from applications-end folk like you, things won't improve. It's incredibly valuable feedback. But I can see that when you have to deliver something next week you can't wait around for some someone to get around to fixing your problem. (They aren't paid either!) Maybe you can use Haskell for something less mission-critical, so that you can keep up the pressure? Meanwhile, let me utter my customary encouragement to the Haskell community out there: please pitch in and help! Haskell will only break into real applications, of the kind Joel has been writing, if we can offer robust libraries, and that depends utterly on you. Don't wait for someone else to do it. Simon

5 5

RE: [Haskell-cafe] Project postmortem
by Simon Marlow 19 Nov '05

19 Nov '05

On 18 November 2005 14:42, Joel Reymont wrote: > On Nov 18, 2005, at 1:55 PM, Simon Marlow wrote: > >> You can get debugging output by compiling your program with -debug, >> and then running it with some of the -D<something> options (use +RTS >> -? for a list, +RTS -Ds is a good one to start with). > > I'm still working on a repro case but here's what I get... > > +RTS -Ds > ... > scheduler: checking for threads blocked on I/O > sched: -->> running thread 1103 ThreadRunGHC ... > sched: --<< thread 1103 (ThreadRunGHC) stopped: is blocked on an MVar > all threads: > thread 1225 @ 0x1539000 is not blocked > thread 1224 @ 0x1506aa4 is not blocked > thread 1223 @ 0x15066a4 is not blocked > ... > scheduler: checking for threads blocked on I/O > sched: -->> running thread 1107 ThreadRunGHC ... > Segmentation fault > > 1107 is not blocked in the list of all threads. What options should I > try next? That doesn't tell us much unfortunately. Can you send a disassembly of the block in which the crash happened? Is it always the same block, BTW? Does changing the heap size (+RTS -H<size>) have any effect? Cheers, Simon

3 3