- Haskell-Cafe - Haskell.org

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

Non-technical Haskell question
by GoldPython 10 Dec '04

10 Dec '04

Hi, all, I'm new to the Cafe, but not to Haskell (experimented with it on and off on a small scale over the last 5 or 6 years and enjoy the language quite a lot) and had more of a political question and wanted to see what people thought: Has anyone tried presenting the language to the average rank and file programming community? If so, was it successful? If not, is there interest in doing so? By "rank and file" I mean, outside of the acedemic world where a large number of the programmers I see have very little math background. This would be the typical commercial Visual Basic crowd and the like. Thanks, Will Collum

23 49

Re: [Haskell-cafe] Parse text difficulty
by David Menendez 10 Dec '04

10 Dec '04

Conor McBride writes: > Jan-Willem Maessen - Sun Labs East wrote: > > Tomasz Zielonka wrote: > > > >>I found it useful recently, when I needed zip functions for Trees - > >>this way I didn't have to define functions for 3 trees, 4 trees, > >>and so on. > > > > > > Note also that: > > > > repeat f `zwApply` xs = map f xs > > > > When cooking up my own collection-y things (including splittable > > supplies, for example), I generally provide fmap and an equivalent > > of zwApply (a generic repeat is not quite so simple or useful). > > It's a nice little idiom, and a recommend it highly. > ^^^^^ > > Funny you should choose that word: > > http://www.mail-archive.com/haskell@haskell.org/msg15073.html > > saves me banging the same old drum. Now that I think about it, you can generalize the trick I mentioned elsewhere to work over any Idiom/Sequence/more-than-a-functor-not-yet-a-monad thingy. > class Sequence f where > unit :: a -> f a > (<*>) :: f (a -> b) -> f a -> f b > > liftN :: Sequence f => (f a -> b) -> a -> b > liftN d f = d (unit f) > > suc :: Sequence f => (f b -> c) -> f (a -> b) -> f a -> c > suc d f x = d (f <*> x) > > zero = id > > one :: Sequence f => f (a -> b) -> f a -> f b > one = suc zero > > two :: Sequence f => f (a -> b -> c) -> f a -> f b -> f c > two = suc one > > > newtype L1 a = L1 { unL1 :: [a] } > newtype L2 a = L2 { unL2 :: [a] } > > > instance Idiom L1 where > unit x = L1 [x] > L1 fs <*> L1 xs = L1 [ f x | f <- fs, x <- xs ] > > instance Idiom L2 where > unit x = L2 (repeat x) > L2 fs <*> L2 xs = L2 (zipWith ($) fs xs) *Main> unL1 $ liftN two (,) (L1 [1,2,3]) (L1 "abc") [(1,'a'),(1,'b'),(1,'c'),(2,'a'),(2,'b'),(2,'c'),(3,'a'),(3,'b'),(3,'c') ] *Main> unL2 $ liftN two (,) (L2 [1,2,3]) (L2 "abc") [(1,'a'),(2,'b'),(3,'c')] -- David Menendez <zednenem(a)psualum.com> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!"

2 1

ghc has problems with 'zipWith' ?
by Derek Elkins 10 Dec '04

10 Dec '04

> Is it possible and senseful for a compiler to extract common > sub-expressions? Naively I think that for a given tree of an > expression it is efficiently possible to find all common sub-trees. > Referential transparency would assure that equal expressions have the > same value, so they can be replaced by the same object. E.g. the > example above could be automatically transformed to: > > ms as = > let tmp0 = zipWith (+) (zipWith (*) as tmp1) (0:tmp1) > tmp1 = 1:tmp0 > in tmp0 It's possible and will preserve semantics, but isn't always an optimization. http://www.haskell.org/pipermail/haskell-cafe/2003-December/005574.html

2 1

Parse text difficulty
by Derek Elkins 09 Dec '04

09 Dec '04

> Robert Dockins <robdockins at fastmail.fm> writes: > > > > And I thought that most programmers used "zipWith", which has to > > > be prefix. > > > [1..5] `zipWith (+)` [7..] > > You don't have a computer at your end of the internet? :-) > > Prelude> [1..5] `zipWith (+)` [7..] > <interactive>:1: parse error on input `(' > Prelude> let zwp = zipWith (+) in [1..5] `zwp` [7..] > [8,10,12,14,16] A way to accomplish the above is given on http://www.haskell.org/hawiki/InfixExpression Also for those who haven't looked too hard at the wiki (or at all), http://www.haskell.org/hawiki/CommonHaskellIdioms is probably the most densely packed page of information on it and makes a great starting point for finding answers on the wiki. The above link is on it, and also the perennial questions about making functions strict is on it under section "Efficiency" "ForcingEagerEvaluation" (where you'll find things like DeepSeq), and some documentation on Control.Monad.* modules under MonadTemplateLibrary. So, just in general, it's a useful and interesting page, and many posts to haskell(-cafe) can be avoided just by perusing it.

1 0

RE: [Haskell-cafe] Non-technical Haskell question
by azrael＠demonlords.net 09 Dec '04

09 Dec '04

> -------- Original Message -------- > Subject: Re: [Haskell-cafe] Non-technical Haskell question > From: "Keith Wansbrough" <Keith.Wansbrough(a)cl.cam.ac.uk> > Date: Mon, December 06, 2004 9:00 am > To: "Georg Martius" <mai99dgf(a)studserv.uni-leipzig.de> > Cc: "Jason Bailey" <azrael(a)demonlords.net>, "Jules Bean" > <jules(a)jellybean.co.uk>, Haskell-Cafe(a)haskell.org > > > > When I compile it I get three files, an actual runnable binary (at only > > > 5M in size), a .o file and a .hi file. I'm sure these additional files > > > are usefull in someway and as soon as I come across the right piece of > > > documentation everything should make sense. But as a person new to the > > > language I'm just left wondering why. > > gcc of course leaves .o files lying around, so this is no different than C. > > javac often creates tens or hundreds of .class files, some with > strange names like MyClass$1.class, MyClass$2.class, and so on (yes, I > know what they are for), and doesn't even generate a native binary. The original observation was that the compiler seems archaic. When asked, I gave some general comments. What I should have just said was that it was to much like a C compiler. Which, no matter how neat you think it is, is archaic. When I use javac every file that is created is necessary for the application to run. This can't be said of the ghc compiler. Having an excuse that this is way the C compiler does it or that this is the way its always been done is to poor of a reason to even argue against. If a file isn't needed then it shouldn't be left there. > I don't think the output of ghc is any more surprising than these; I'm > surprised it bothers you. > Does this bother me? Not in particular, its just an indication that this is an old design. > The static vs dynamic linking question has been discussed many times. > The summary is: GHC is a highly-optimising compiler, and the binary > interface _necessarily_ changes with every minor revision (even > patchlevel revision) of the compiler and each library. So you can't > sensibly share libraries between apps. Anyway, disc is cheap. > I design and build business applications. I'm very good at this. Part of being very good at something like that is acknowledging that that there are some areas where I can't be as good.. such as compilers. The reason I say this is that if your telling me that no one here can figure out how to make it work then I will take your word for it. I'm certainly not in a position to argue :) The whole disc is cheap argument is a cop out. Certainly for a single application this is true. But your inherently limiting yourself. This means no one would consider haskell for embedded devices, or an OS, and it would even impact to a certain degree the decision to use it for a commericial product. You can see how this is reflected today in the fact that you can find almost no binary programs available for download. Programs and applications are out there but almost exclusivly as source code and yes a few of the website even mention that the binary size is the reason why they aren't making it available. (bandwith costs time and money) However this is just a view of a rank and file programmer who's new to haskell. Some of my concerns and issues are probably not valid just because I am not familiar with the language as a whole. However if there is a desire to make Haskell more accessible to the majority of programmers then the first impressions that I, and those like me have is important. Jason > HTH. > > --KW 8-)

20 21