November 2001 - Haskell-Cafe

Strictness making it worst?
by Jorge Adriano 29 Nov '01

29 Nov '01

Hi, I've just started messing around with strictness. My goal now is understanding when and how to use it. I began with simple examples like making a strict foldl. When trying to sum a list of 60000 elements with lazy foldl I'd get a stack space overflow, with a strict foldl I was able to sum a list of 1E8 elements :) Then I thought I'd mess with the fibonnaci function. I began with: > fibac :: IntPos -> (IntPos,IntPos) -> (IntPos,IntPos) > fibac n (a,b) > | n == 0 = (a,b) > | otherwise = fibac (n-1) (b,a+b) Then I tried: > sfibac :: IntPos -> (IntPos,IntPos) -> (IntPos,IntPos) > sfibac n (a,b) > | n == 0 = (a,b) > | otherwise = sfibac (n-1) (b, (+b) $! a) I tried both functions with ghc 5.00.1 The strict version was not only slower, but I'd get stack overflows for numbers that worked with the 1st version!! (like 100000) I expect sfibac and fibac work this way: assuming that a+b = c b+c = d c+d = e sfibac: sfibac 4 (a, b) -> sfibac 3 (b, a+b) -> sfibac 2 (a+b, b+(a+b)) -> sfibac 1 (b+(a+b), (a+b)+(b+(a+b))) -> sfibac 0 ((a+b)+(b+(a+b)), (b+(a+b)) + (a+b)+(b+(a+b))) now if I had to evaluate the first element I'd get (a+b)+(b+(a+b)) -> c+(b+c) -> c+d -> e fibac: sfibac 4 (a, b) -> sfibac 3 (b, a+b) -> sfibac 2 (c, b+c) -> sfibac 1 (d, c+d) -> sfibac 0 (e, d+e) I'd expect sfibac to be faster, but what I find even more strange is the stack space overflow in sfibac! why? Greetings, J.A.

2 1

Re: Strictness making it worst?
by Jorge Adriano 29 Nov '01

29 Nov '01

> Then I tried: > > sfibac :: IntPos -> (IntPos,IntPos) -> > > (IntPos,IntPos) sfibac n (a,b) > > > > | n == 0 = (a,b) > > | otherwise = sfibac (n-1) (b, (+b) $! a) I'm sorry I meant: > sfibac :: IntPos -> (IntPos,IntPos) -> > (IntPos,IntPos) sfibac n (a,b) > > | n == 0 = (a,b) > | otherwise = sfibac (n-1) (b, (a+) $! b) otherwise the reductions would be wrong > fibac: > sfibac 4 (a, b) -> > sfibac 3 (b, a+b) -> > sfibac 2 (c, b+c) -> > sfibac 1 (d, c+d) -> > sfibac 0 (e, d+e) In fact I would expect that using ((a+) $! b) would be better than (b, (+b) $! a), but the 1st seemed to be the worst in terms of both speed and stack space problems. J.A.

1 0

Re: categorical prelude
by Christopher Milton 27 Nov '01

27 Nov '01

Oops, that should have been "Constructor Classes". --- Christopher Milton <cmiltonperl(a)yahoo.com> wrote: > I have a copy of the paper by Erik Meijer and Luc Duponcheel, > "On the expressive power of Combinator Classes", but I can't > seem to find a copy of the prelude file anywhere. > > Has anyone still got a copy anywhere? > > I look to hearing from you. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

1 0

categorical prelude
by Christopher Milton 27 Nov '01

27 Nov '01

I have a copy of the paper by Erik Meijer and Luc Duponcheel, "On the expressive power of Combinator Classes", but I can't seem to find a copy of the prelude file anywhere. Has anyone still got a copy anywhere? I look to hearing from you. ===== Christopher M. Milton cmiltonperl(a)yahoo.com Phone 719/380-7665 Colorado Springs, CO __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

1 0

RE: Asynchronous Exceptions
by Simon Marlow 27 Nov '01

27 Nov '01

> On Fri, Nov 23, 2001 at 09:38:35AM -0000, Simon Marlow wrote: > > > [...] > > > However, I agree that sometimes you really want to be able > to do this, > > so perhaps we need another form of 'block' which doesn't allow *any* > > exceptions to be delivered, for those times when you know > that the time > > spent waiting in an interruptible operation is going to be bounded. > > But even things like putStr can block for an unbounded amount of > time. E.g. stdout is a pipe and the reader just doesn't read it for > n hours (n unknown), etc. Sure, which is why we don't allow the programmer to make these non-interruptible. But there are other ways to shoot yourself in the foot: you can go into an infinite loop inside a block, for example. I think there are certain cases where you want to break the rules slightly, and force a particular interruptible operation to be non-interruptible, so that you can guarantee a particular sequence will always run to completion. Sometimes there's just no way to get where you're going otherwise. In the example above, the programmer might know that the pipe is always going to be read within a certain time. You could spin instead of blocking in many cases: for MVars we have the non-blocking tryTakeMVar and tryPutMVar, but for IO we only have hInputReady which works if you're the only thread using that particular Handle, otherwise there's a race window between calling hInputReady and actually doing the IO. So suppose the programmer is going to use the non-blocking versions of these primitives and poll the resource instead of waiting for it. We might as well provide non-interruptible blocking operations (or a non-interruptible version of 'block') and save ourselves some CPU cycles. The onus is on the programmer to ensure that the sequence can't block indefinitely. Cheers, Simon

1 0

i can't see the solution
by Fwd 25 Nov '01

25 Nov '01

it's an .lhs file > data Alumno = A { dni :: Integer, nombre :: String,nota::Float } > shf :: Alumno -> String > shf alum = show (dni alum) ++ nombre alum ++ show (nota alum ) i don't wanna use this sentence: deriving Show i wanna use "my show function" but ... Here is the problem !! > instance Show a => Show (Alumno a) where > show x = shf x Thanks .

1 0

Re: Why no exceptions in Haskell?
by Marcin 'Qrczak' Kowalczyk 23 Nov '01

23 Nov '01

Fri, 23 Nov 2001 07:12:10 +1100, Fergus Henderson <fjh(a)cs.mu.oz.au> pisze: > ... and the main reason why Haskell 98 didn't incorporate this is because, > well, 98 was before 99 ;-). In order for exceptions to be practical, one should be able to throw other types than the builtin IOError which roughly corresponds to errno in C. In GHC Dynamic is used for this. IMHO exceptions should not be standarized without such capability. I don't like Dynamic much but no other solution has been designed for Haskell. Maybe some kind of extensible datatypes would be better, preferably not limited to exceptions. It has other problems though, for example how to define functions like (==) for extensible datatypes? A static type system sometimes do get in the way! Python people have some right in saying this. (But IMHO they are wrong in saying that very small amount of errors is catched by static typing.) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

VIRUS ALERT Read this first. (Was Fwd: Re some MP3s here hehe ;-) )
by Theodore Norvell 23 Nov '01

23 Nov '01

The message entitled Fwd: Re some MP3s here hehe ;-) not only doesn't belong on the list, but also contains a virus. Happy Haskelling, Theodore Norvell

1 0

Fw: Re: some mp3s here hehe ;-)
by daan＠cs.uu.nl 22 Nov '01

22 Nov '01

1 0

Why no exceptions in Haskell?
by Michael Marte 22 Nov '01

22 Nov '01

Hello *, I am just curious: Why does Haskell not provide exceptions a la SML? Why does only the IO monad allow for exceptions? Michael

4 3