- Glasgow-haskell-users

Replacing the Prelude
by Ashley Yakeley 14 May '02

14 May '02

I have recently been experimenting writing code that replaces large chunks of the Prelude, compiling with -fno-implicit-prelude. I notice that I can happily redefine numeric literals simply by creating functions called 'fromInteger' and 'fromRational': GHC will use whatever is in scope for those names. I was hoping to do something similar for 'do' notation by redefining (>>), (>>=) etc., but unfortunately GHC is quite insistent that 'do' notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad, as the Report seems to require). I don't suppose there's any way of fooling it, is there? I was rather hoping 'do' notation would work like a macro in rewriting its block, and not worry about types at all. I accept that this might be a slightly bizarre request. There are a number of things I don't like about the way the Prelude.Monad class and 'do' notation are set up, and it would be nice to be able to experiment with alternatives. -- Ashley Yakeley, Seattle WA

2 1

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

14 May '02

At 2002-05-14 03:57, Simon Marlow wrote: >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). Under what circumstance would the compiler do this to my code? I really need to know about any deviation from the semantics. >so your catch can be defined in terms of the current catch like so: > > catch' a h = a `seq` (catch a h) Oh yeah. >what's the motivation for this change? Well I think it's more intuitive. The documentation (sec. 5.12.3) says this: The simplest version is catch. It takes a single argument, runs it, and if an exception is raised the "handler" is executed passing the value of the exception. Otherwise, the result is returned as normal. ...leading to the question, how do you 'run' bottom? But since I can do what I want with your "catch'" function, it's not really that important. -- Ashley Yakeley, Seattle WA

1 0

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