RE: Prelude.catch vs. Exception.catch
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Prelude.catch vs. 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. 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Prelude.catch vs. Exception.catch
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing the Prelude
On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote:
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.
A while ago, there were extensive discussions about replacing the
Prelude on this list. (Search for Prelude shenanigans.) I started
to write up a design document for how to enable replacing the Prelude.
This boiled down to taking most of the syntactic sugar defined in
the report seriously, ignoring the types (as you say).
I'm surprised that ghc uses the fromInteger and fromRational that are
in scope; I thought there was general agreement that it should use the
Prelude.from{Integer,Rational} in scope.
As I recall, there were several relevant bits of syntactic sugar:
- Numeric types, including 'fromInteger', 'fromRational', and
'negate'. This all works fine, except that the defaulting mechanism
is completely broken, causing a number of headaches.
- Monads. The translation given in the report is clean, and it seems
like it can be used without problems.
- Bools. There was a slight problem here: the expansion of
'if ... then ... else ...' uses a case construct referring to the
constructors of the Bool type, which prevents any useful
redefinition of Bool. I would propose using a new function,
'Prelude.ifThenElse', if there is one in scope.
- Enumerations. Clean syntactic sugar.
- List comprehensions. The report gives one translation, but I think
I might prefer a translation into monads.
- Lists and tuples more generally. At some point the translations
start getting too hairy; I think I decided that lists and tuples
were too deeply intertwined into the language to change cleanly.
I'll dig up my old notes and write more, and then maybe write a
complete design document and get someone to implement it.
--Dylan Thurston
msg03485/pgp0.pgp
Description: PGP signature
RE: Replacing the Prelude
Ashley writes
| 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
Dylan replies
| I'm surprised that ghc uses the fromInteger and fromRational
| that are in scope; I thought there was general agreement that
| it should use the Prelude.from{Integer,Rational} in scope.
Ashley is referring to a GHC extension. Normally, GHC uses
Prelude.fromInteger etc, regardless of what is in scope. But if you
say -fno-implicit-prelude, GHC will instead use whatver fromInteger
is in scope. (This is documented in the manual.)
Ashley's question, as I understand is whether something similar
could be done for monads.
Answer: I think so, without much bother. I'm beavering away on
a Haskell workshop paper at the moment, but ping me in a fortnight
to do it.
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
