I thought about this problem some more, and I have realized that the
problem of nondeterminacy for Haskell exceptions would in fact be
considerably worse that I had previously considered. The trouble is
that in the general case the problem is not just that the choice of
which exception is
At 11:06 +0200 98/06/16, Erik Zuurbier wrote:
... Exceptions are merely a way to structure
the code, so that the main line and error handling can be neatly separated.
This is the original idea, but I pointed out that exceptions are in fact
much deeper: They can be used as a programming
On Tue, 16 Jun 1998, Erik Zuurbier wrote:
I have read many, but not all of the messages on this subject. Did any of those
shed any light on the intended use of exceptions? Maybe that could explain
the disagreement. I can imagine:
1) You use exceptions for debugging your program, with the
At 14:40 +0100 98/06/10, Simon L Peyton Jones wrote:
Here's a reasonable design for exceptions in Haskell:
A think one can use a monadic approach, as a monad
(X, unit_X, bind_X): HaskellX - HaskellX
where HaskellX is and extension of Haskell with exceptions.
* A value of Haskell type T
On 16-Jun-1998, Simon L Peyton Jones [EMAIL PROTECTED] wrote:
[Fergus wrote:]
I thought about this problem some more, and I have realized that the
problem of nondeterminacy for Haskell exceptions would in fact be
considerably worse that I had previously considered. The trouble is
that
SLPJ writes:
So I appear to be in disagreement here with Alex, Amr, and Fergus about
the importance of being able to say precisely which exception is raised.
I'm quite content with knowing which *set* of exceptions can be raised.
I have read many, but not all of the messages on this subject.
On 12-Jun-1998, Alastair Reid [EMAIL PROTECTED] wrote:
Fergus Henderson [EMAIL PROTECTED] points out that our exception handling
scheme hits problems if you hit an infinite loop instead of an exception.
Yes, this is a problem - and not a pretty one.
Fixes:
...
3) Add timeouts (and
On 11-Jun-1998, Amr A Sabry [EMAIL PROTECTED] wrote:
There is one aspect of Java that is relevant here:
A Java implementation is free to load and link classes in any order,
strictly or lazily, but it MUST report exceptions as if it had loaded
and resolved the classes lazily.
I think
Fergus Henderson [EMAIL PROTECTED] points out that our exception handling
scheme hits problems if you hit an infinite loop instead of an exception.
Yes, this is a problem - and not a pretty one.
Fixes:
1) Remove fixpoints so that infinite loops don't happen.
Ok, so this isn't really an
On 10-Jun-1998, S. Alexander Jacobson [EMAIL PROTECTED] wrote:
This sounds like what I wanted. Just a few questions:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
On 10-Jun-1998, S. Alexander Jacobson [EMAIL PROTECTED] wrote:
On Thu, 11 Jun 1998, Fergus Henderson wrote:
It would make debugging easier if the exception picked was consistent
accross implementations. It doesn't matter which one, but it does matter
that it is the same. (maybe you
One of the wonderful things about functional languages is that they
do not prescribe the order of evaluation. To achieve the effect you
want would require us to completely prescribe that order, with very
bad effects on efficiency. For example, consider
...
But if we are required to ensure
I was keeping quiet myself, because I am planning to write
a paper touching on this topic. But the cat seems to be
mostly out of the bag now, so I might as well pipe up.
I'm glad you did. That's a neat idea. I'm familiar
with the NDSet idea -- that's in the Hughes/O'Donnell
paper that
Just to reiterate. I strongly urge you to ensure consistent exception
behavior. As a matter of course, two different compiles should not result
in two different programs.
One of the wonderful things about functional languages is that they
do not prescribe the order of evaluation. To
Alastair Reid has been very quiet, so I'll pipe up for him.
Here's a reasonable design for exceptions in Haskell:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
* raise :: String - a
* handle :: (String - IO a) - IO a - IO a
I'd be interested to know what people think of this.
I like the trick of handle being in the IO monad to avoid
problems with evaluation order. As usual though, it can be a
high price to pay if all you wanted was a little local
I'd be interested to know what people think of this.
Here's a reasonable design for exceptions in Haskell:
...
The neat thing about this is that the exceptions can
be *raised* in arbitrary purely functional code, without
violating referential transparency. The question of
which exception
Thats a wonderful idea. With that it will be so much easier to write
robust code without bloating the code with error checks.
I've always been annoyed that I couldn't trap arbitrary errors, say to
close down the application cleanly.
Now, we only need extendible data types, and then we have an
Simon and Alastair,
This sounds like what I wanted. Just a few questions:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
OR it can be a set of exceptional values.
On Wed, 10 Jun 1998, Simon L Peyton Jones wrote:
| We're implementing an experimental version of this
| in GHC, integrated with the IO monad exceptions, so that
|
| handle :: (IOError - IO a) - IO a - IO a
|
| and we add an extra constructor (UserError String) to the
| IOError type
At 2:40 pm 10/6/98, Simon L Peyton Jones wrote:
Here's a reasonable design for exceptions in Haskell:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
OR it can be a
On Thu, 11 Jun 1998, Fergus Henderson wrote:
It would make debugging easier if the exception picked was consistent
accross implementations. It doesn't matter which one, but it does matter
that it is the same. (maybe you require that Exceptions implement Ord,
or sort based on the
22 matches
Mail list logo
