- Haskell-Cafe - Haskell.org

Processing File Dependencies
by chris beddoe 11 Dec '04

11 Dec '04

2 1

Flattening tail recursion?
by Derek Elkins 11 Dec '04

11 Dec '04

> intermediate thunk has already been built. You need a separate "strict > foldl" function, usually called foldl', which was unaccountably > omitted from the prelude. There is one in Data.List.

1 0

Haskell IO and exceptions
by Mark Carroll 11 Dec '04

11 Dec '04

All this talk of IO and exceptions reminds me of a small issue I've been having. I like Control.Monad.Error but often my stuff is threaded through the IO monad so, AFAICT from the functional dependency stuff, that means my errors have to be IOErrors. Is that right? And, then, I want control over what's actually reported to the user, but if I make a userError than the consequent message (where the details are presumably platform-dependent) is wrapped up in extra text that I didn't want appearing. Can I use Control.Monad.Error for IO monad stuff such that I can control what string will appear when my error handler tries to "show" my exception? Admittedly, I'm still learning my way around this bit of the standard libraries, so I may have missed something obvious. -- Mark

3 2

Re: [Haskell-cafe] hGetLine problem
by Keean Schupke 10 Dec '04

10 Dec '04

Hmm, I dont see why the main process would be affected... It should be able to accept multiple connections in parallel. Is it just hGetLine that causes the problem... what if you use hGetContents instead? Does it still not work? (I have a sever implemented - I tested it with "ab -n100 -c10" with no problems...) Keean. Michael Walter wrote: >I did that -- the main process doesn't die, anyway, it just seems to "hang". > >- Michael > > >On Fri, 10 Dec 2004 16:27:05 GMT, MR K P SCHUPKE ><k.schupke(a)imperial.ac.uk> wrote: > > >>>But if the forkIO'ed process terminates because of an exception, that >>>shouldn't influence the main process, right? >>> >>> >>Well, if its unix you might have to set sigPIPE to Ignore... >> >>Otherwise, the main process should not die just because the child has... >> >> Keean. >> >> >>

2 1

RE: [Haskell-cafe] Parse text difficulty
by Simon Marlow 10 Dec '04

10 Dec '04

On 09 December 2004 16:37, Malcolm Wallace wrote: > Robert Dockins <robdockins(a)fastmail.fm> writes: > >>> Prelude> [1..5] `zipWith (+)` [7..] >>> <interactive>:1: parse error on input `(' >> >> is there a technical reason for this or did it just happen? > > If you are asking why general expressions are prohibited between > backticks, yes, there is a reason. The expression could be > arbitrarily large, so you might have to search many lines to find the > closing backtick. But in such a situation, it is surely much more > likely > that the programmer has simply forgotten to close the ticks around > a simple identifier. Just think of the potential for delightfully > baffling type error messages that might result! Forgetting to close a tick would lead to an odd number of ticks, which would probably be flagged as a parse error. Unless you had an even number of missing ticks, of course :-) You can't allow completely general expressions inside backticks, otherwise you run into ambiguity with: 1 `plus` 2 + 3 `plus` 4 so, is that (plus 1 2) + (plus 3 4) or is it ((2+3) plus plus) 1 4 So it would have to be `fexp` only (see the Haskell grammar for fexp). And there's fixities: you can specify the fixity of `x`, but it doesn't make sense to specify the fixity of an expression. There's a historical reason too: `x` and (+) used to be single lexical tokens. I think that changed in Haskell 1.3, but I could be mistaken. Cheers, Simon

1 0

Re: [Haskell-cafe] hGetLine problem
by MR K P SCHUPKE 10 Dec '04

10 Dec '04

>But if the forkIO'ed process terminates because of an exception, that >shouldn't influence the main process, right? Well, if its unix you might have to set sigPIPE to Ignore... Otherwise, the main process should not die just because the child has... Keean.

1 0

hGetLine problem
by Michael Walter 10 Dec '04

10 Dec '04

Herro, thanks for your feedback on my last question, it helped quite a bit. I continued toying with my toy web server, and I'm "sometimes" getting "Invalid argument" errors in hGetLine for a handle I retrieved from Network.listenOn. "Sometimes", because it works fine in the browser, except when I reload very frequently -- maybe it's related to some concurrency issues (I'm using forkIO to spawn off the handler process from the main server loop). When I wanted to benchmark the server using "ab" (Apache Benchmark), it didn't even "survive" one request but Fail'ed using that error message - "<handle: n>: hGetLine: Invalid argument". I tried adjusting the buffering mode. Do you have any ideas? Cheers, Michael

3 7

RE: [Haskell-cafe] Flattening tail recursion?
by Bayley, Alistair 10 Dec '04

10 Dec '04

http://haskell.org/hawiki/TailRecursive A common technique to make a function tail-recursive is to introduce an accumulating parameter, although in the 5 minutes I've spent looking on the wiki, there's no specific page for this. Perhaps add a link from the Efficiency section on http://haskell.org/hawiki/CommonHaskellIdioms ? > -----Original Message----- > From: GoldPython [mailto:goldpython@gmail.com] > Sent: 10 December 2004 15:07 > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Flattening tail recursion? > > I'm missing something, a functional idiom, whatever. I know there's > "length" to count the elements in a list and it works fine, but the > function below stack overflows on a large list. > > countLines [] = 0 > countLines (_:ls) = 1 + countLines ls > > I would have thought that this was tail recursive and would be > flattened into iteration by the compiler. Can anyone explain why? Is > it because the call is embedded in an expression? > > And additionally, how can I predict when the flattening will occur? > > Thanks, > Will > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Re: [Haskell-cafe] Parse text difficulty
by MR K P SCHUPKE 10 Dec '04

10 Dec '04

Oops, please ignore, I just replied to the wrong emaiL! Keean.

1 0

Re: [Haskell-cafe] Parse text difficulty
by MR K P SCHUPKE 10 Dec '04

10 Dec '04

At the moment the unix encrypted passwords are downloaded using sov_slave (an application written by ICT that talks directly to the SOV database)... As far as I am aware all unix cluster in college that are part of ICTs single sign-on us this method unless you have recently changed them... I am suggesting that if there are currently no restrictions on which machines can download using sov_slave, then such restrictions should be put in place. We use scp to update the shadow password files directly on each machine, so the unix crypted password is not exposed (except on a legacy YP domain which is not used by us anymore for password authentication)... I should be able to disable this YP domain, in which case there would be no exposure of the unix passwords, except the possiblility of snooping the sov_slave transfer. This in turn could be done over an encryted SSH tunnel, removing _all_ exposure of the passwords. (we would still download using sov_slave - but as we would authenticate using an ssh key, and only the shadow files would be updates there would be no exposure)... Anyway that is all temporary, we intend to move to Kerberos, once I have sorted out a couple of issues (like ACLs for restricted access machines). Keean.

1 0