May 2002 - Glasgow-haskell-users

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

14 May '02

> At 2002-05-14 02:58, Simon Marlow wrote: > > >I must admit I can't think of any compelling reasons for the change, > >other than the fact that this is functionality that we don't > have at the > >moment, and therefore might be useful. Opinions? > > I need a function that does this: > > evaluate :: a -> IO a > evaluate _|_ = fail something > evaluate a = return a > > The idea is that you can take something that might be bottom > and safely > handle it in the IO monad, with the "bottomness" gone. This is what > Exception.evaluate currently does, and I think that's correct. Ok, I'll change the definition of evaluate to reflect the slightly different semantics. It turns out that the compiler "bug" is really just the compiler being a bit loose with the IO monad - it freely translates the original definition of evaluate using 'seq' into the slightly less strict version by pushing the 'seq' through the state lambda of the IO monad (this only happens for the IO monad, and strictly speaking it's a deviation from the semantics but it has important performance benefits for IO code). > I think the behaviour of Exception.catch is wrong. I think it should > behave like this: > > catch _|_ cc = _|_ > catch (failure ex) cc = cc ex > catch (success a) cc = success a > > ...whereas it actually behaves like this: > > catch _|_ cc = cc something > catch (failure ex) cc = cc ex > catch (success a) cc = success a so your catch can be defined in terms of the current catch like so: catch' a h = a `seq` (catch a h) what's the motivation for this change? Cheers, Simon

1 0

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

14 May '02

At 2002-05-14 02:58, Simon Marlow wrote: >I must admit I can't think of any compelling reasons for the change, >other than the fact that this is functionality that we don't have at the >moment, and therefore might be useful. Opinions? I need a function that does this: evaluate :: a -> IO a evaluate _|_ = fail something evaluate a = return a The idea is that you can take something that might be bottom and safely handle it in the IO monad, with the "bottomness" gone. This is what Exception.evaluate currently does, and I think that's correct. I think the behaviour of Exception.catch is wrong. I think it should behave like this: catch _|_ cc = _|_ catch (failure ex) cc = cc ex catch (success a) cc = success a ...whereas it actually behaves like this: catch _|_ cc = cc something catch (failure ex) cc = cc ex catch (success a) cc = success a -- Ashley Yakeley, Seattle WA

1 0

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

14 May '02

> >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. > > I might ask which is correct: according to the rules for seq, > "evaluate' > undefined" should be bottom, but we want "Expression.evaluate > undefined" > to be a failing IO action. > > I think the compiler is correct but the definition given in the > documentation is wrong. Well, given the compiler is compiling the definition from the documentation and giving the wrong semantics, I'd say the compiler is definitely wrong :-) But the question of whether Exception.evaluate should have a different semantics is interesting. So to be clear about this, there are three possible definitions of evaluate: evaluate a = return a -- not strict enough evaluate a = a `seq` return a -- too strict (?) evaluate a = IO $ \s -> a `seq` (# s, a #) -- just right :) I had to write out the third one in full, because we don't have any combinators that provide this functionality elsewhere (at least, I can't think of any). I must admit I can't think of any compelling reasons for the change, other than the fact that this is functionality that we don't have at the moment, and therefore might be useful. Opinions? Cheers, Simon

1 0

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

14 May '02

At 2002-05-14 02:24, Simon Marlow wrote: >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. I might ask which is correct: according to the rules for seq, "evaluate' undefined" should be bottom, but we want "Expression.evaluate undefined" to be a failing IO action. I think the compiler is correct but the definition given in the documentation is wrong. -- Ashley Yakeley, Seattle WA

1 0

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