- Glasgow-haskell-users

RE: Prelude.catch vs. Exception.catch
by Simon Marlow 14 May '02

14 May '02

> At 2002-05-13 22:07, Ashley Yakeley wrote: > > >I've noticed something a bit unusual about Exception.catch. > > Curiously, the definition of Exception.evaluate given in the GHC > Libraries documentation sec. 5.12.3 is not that actually > implemented by > GHC. > > evaluate' :: a -> IO a; > evaluate' a = a `seq` return a; > > "evaluate' undefined" is bottom, whereas "Expression.evaluate > undefined" > is an IO action that "fails" when executed. But both will be > caught by Exception.catch. This is bizarre: the definition of evaluate in Exception is exactly the one you gave above, yet they behave differently. You may have uncovered a compiler bug, I'll look into it. Cheers, Simon

1 0

RE: Prelude.catch vs. Exception.catch
by Simon Marlow 14 May '02

14 May '02

> >The idea is > >that if you want to use Exceptions in their full glory, you: > ... > > import qualified Exception > > I've noticed something a bit unusual about Exception.catch. > It seems it > can't catch "return undefined" by itself. Consider these > values of type > "IO String": > > iouPure :: IO String; > iouPure = undefined; > > iouError :: IO String; > iouError = error "error"; > > These aren't even an IO actions, they're simply bottom. > Straightforward > enough. But they _will_ be caught by Exception.catch. > > iouFail :: IO String; > iouFail = fail "failure"; > > iouEvaluate :: IOString; > iouEvaluate = Exception.evaluate undefined; > > These two are IO actions that "fail" when executed. They will also be > caught by Exception.catch. > > iouReturn :: IO String; > iouReturn = return undefined; > > This one is an IO action that "succeeds" when executing. It > _won't_ be > caught by Exception.catch, which will instead simply return > the undefined > value. > > I'm not sure what to make of this... This is just an artifact of the laziness of 'return'. One of the monad laws is return a >>= k = k a so therefore return undefined >>= (\_ -> m) = m so return can't be strict. Since return isn't strict, return undefined `seq` a = a So that's really why we have Exception.evaluate: it's a strict version of return. Cheers, Simon

1 0

RE: Prelude.catch vs. Exception.catch
by Ashley Yakeley 14 May '02

14 May '02

At 2002-05-13 22:07, Ashley Yakeley wrote: >I've noticed something a bit unusual about Exception.catch. Curiously, the definition of Exception.evaluate given in the GHC Libraries documentation sec. 5.12.3 is not that actually implemented by GHC. evaluate' :: a -> IO a; evaluate' a = a `seq` return a; "evaluate' undefined" is bottom, whereas "Expression.evaluate undefined" is an IO action that "fails" when executed. But both will be caught by Exception.catch. -- Ashley Yakeley, Seattle WA

1 0

RE: Prelude.catch vs. Exception.catch
by Ashley Yakeley 14 May '02

14 May '02

At 2002-05-13 08:44, Simon Marlow wrote: >Prelude.catch catches IO exceptions only, because this is what the >Haskell report specifies. OK >The idea is >that if you want to use Exceptions in their full glory, you: ... > import qualified Exception I've noticed something a bit unusual about Exception.catch. It seems it can't catch "return undefined" by itself. Consider these values of type "IO String": iouPure :: IO String; iouPure = undefined; iouError :: IO String; iouError = error "error"; These aren't even an IO actions, they're simply bottom. Straightforward enough. But they _will_ be caught by Exception.catch. iouFail :: IO String; iouFail = fail "failure"; iouEvaluate :: IOString; iouEvaluate = Exception.evaluate undefined; These two are IO actions that "fail" when executed. They will also be caught by Exception.catch. iouReturn :: IO String; iouReturn = return undefined; This one is an IO action that "succeeds" when executing. It _won't_ be caught by Exception.catch, which will instead simply return the undefined value. I'm not sure what to make of this... -- Ashley Yakeley, Seattle WA

1 0

RE: Prelude.catch vs. Exception.catch
by Simon Marlow 13 May '02

13 May '02

> I notice that Prelude.catch and Exception.catch behave > differently, even > though they both have the same type signature (and name). > Exception.catch > catches exceptions that Prelude.catch does not. Prelude.catch catches IO exceptions only, because this is what the Haskell report specifies. i.e. the meaning of Prelude.catch undefined (\e -> return 42) should be undefined rather than 'return 42'. We can't change the meaning of Prelude.catch without deviating from Haskell 98. The idea is that if you want to use Exceptions in their full glory, you: import Prelude hiding (catch) import Exception or (my favourite) import qualified Exception Cheers, Simon

1 0

List.sort
by Ian Lynagh 13 May '02

13 May '02

Hi all I am curious as to why the List.sort implementation in GHC is a quicksort algorithm rather than an algorithm that guarantees n log n time in the worst case? I have attached a mergesort implementation along with a few scripts to time it's performance, the results of which are shown below (* means it didn't finish successfully - in all cases this was due to a stack overflow). I am also curious as to the cause of the last failure (this is using the attached mergesort to sort random_list = take 100000 $ randoms $ mkStdGen 100) as it manages with sorted = [1 .. 100000] and revsorted = reverse [1 .. 100000]. Is this because of some optimisations being done for the (rev)sorted cases or is it a problem with randoms? If I heap profile the random_list case with only 10000 then I see random_list peaks at using about 2.5M of memory, whereas in the same program using List.sort it uses only 100k. Input style Input length Sort data Sort alg User time stdin 10000 random_list sort 2.82 stdin 10000 random_list mergesort 2.96 stdin 10000 sorted sort 31.37 stdin 10000 sorted mergesort 1.90 stdin 10000 revsorted sort 31.21 stdin 10000 revsorted mergesort 1.88 stdin 100000 random_list sort * stdin 100000 random_list mergesort * stdin 100000 sorted sort * stdin 100000 sorted mergesort * stdin 100000 revsorted sort * stdin 100000 revsorted mergesort * func 10000 random_list sort 0.31 func 10000 random_list mergesort 0.91 func 10000 sorted sort 19.09 func 10000 sorted mergesort 0.15 func 10000 revsorted sort 19.17 func 10000 revsorted mergesort 0.16 func 100000 random_list sort 3.85 func 100000 random_list mergesort * func 100000 sorted sort 5831.47 func 100000 sorted mergesort 2.23 func 100000 revsorted sort 5872.34 func 100000 revsorted mergesort 2.24 Any comments gratefully received Thanks Ian

2 2

Re: composeList
by David Feuer 13 May '02

13 May '02

See comments below. On Sun, May 12, 2002, David Feuer wrote: > On Sun, May 12, 2002, Emre Tezel wrote: > > Hi all, > > > > I recently bought Simon Thompson's Haskell book. I have been doing the > > exercises while I read on. There are couple questions that I can not > > solve. Any help would be greatly appreciated. > > > > I got stuck on this question in Chapter 10. > > > > Define a function composeList which composes a list of functions into a > > single function. What is the type of composeList? > > > > I naively tried the following but the hugs compiler complained about the > > inferred type not being generic enough. > > > > composeList :: [(a -> b)] -> (c -> b) > > composeList [] = id > > composeList (x:xs) = x . (composeList xs) <snip> > You can do a lot better in Glasgow Haskell: > > data Fun a b = forall c . Comp (c -> b) (Fun a c) | End (a -> b) > > compose :: Fun a b -> a -> b --GHC needs this type signature > --to compile the program, but > --I don't understand why. > --Any tips? > compose (End f) = f > compose (Comp f l) = f . compose l Well, I figured out why the type signature is necessary (polymorphic recursion), but I don't understand the error message I got from GHC: cc.hs:5: Inferred type is less polymorphic than expected Quantified type variable `c' escapes When checking a pattern that binds f :: c -> b l :: Fun a c In the definition of `compose': compose (Comp f l) = f . (compose l) What makes it think that `c' escapes? This message had me staring at the code the wrong way for quite a while before I decided to add a type signature and see if that gave me any more useful information. > > f::Int -> Float > f x = fromIntegral x > > g::String -> Int > g = read > > h::Int -> String > h x = take x "123456789" > > main = do > putStrLn "hello!" > print $ compose (End (\x -> "Foo!")) 3 > print $ compose (Comp f (Comp g (End h))) 4 -- Night. An owl flies o'er rooftops. The moon sheds its soft light upon the trees. David Feuer

1 0

Prelude.catch vs. Exception.catch
by Ashley Yakeley 13 May '02

13 May '02

I notice that Prelude.catch and Exception.catch behave differently, even though they both have the same type signature (and name). Exception.catch catches exceptions that Prelude.catch does not. For instance, it is possible to bind pure functional exceptions into the IO monad using Exception.evaluate: peUndef :: String; peUndef = undefined; ioUndef :: IO String; ioUndef = Exception.evaluate peUndef; These can be caught with Exception.catch: main :: IO (); main = do { result <- Exception.catch (ioUndef) (\e -> return ("got exception: " ++ (show e))); hPutStr stderr (result ++ "\n"); }; got exception: Prelude.undefined ...but not with Prelude.catch: main :: IO (); main = do { result <- Prelude.catch (ioUndef) (\e -> return ("got exception: " ++ (show e))); hPutStr stderr (result ++ "\n"); }; Fail: Prelude.undefined What's up with that? -- Ashley Yakeley, Seattle WA

1 0

RE: ghci unload - profiling
by Simon Marlow 10 May '02

10 May '02

> Just a quick addition to my previous question- using the ghci > linker to > load object code, > I am currently using the following files from the system libraries: > > HSstd.o > HSstd_cbits.o > HSlang.o > HSlang_cbits.o > HSdata.o > HStext.o > HSnet.o > HSconcurrent.o > HSutil.o > HSutil_cbits.o > HSposix.o > HSposix_cbits.o > > However, when tring to profile the code I need to load profiling > versions of these objects, but > the ghci-linkers loadObject doesn't appear to be able to load the > libHSstd_p.a (nor the libHSstd.a) > library... how do I get the ghci-linker to link my profiling objects > against the profiling versions of the > system libraries. You can't do profiling inside GHCi. Compile the program into a standalone binary to do profiling. Cheers, Simon

3 2

RE: bug in ghc with {| |}
by Simon Peyton-Jones 10 May '02

10 May '02

Good point. That was going to be the syntax for type application, but it's not straightforward (e.g. what are the order of the type params?) so I never finished it. I'll remove it from the parser for now. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 07 May 2002 20:19 | To: GHC Users Mailing List | Subject: bug in ghc with {| |} | | | in ghci: | | NLP.Clustering> let x = 5x {| Int |} | *** Exception: typecheck/TcExpr.lhs:168: Non-exhaustive | patterns in function tcMonoExpr | | | i have no idea what {| and |} do, but i was messing around | with them and typed this in by accident and it raised an | exception. fyi. | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0