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
> Simon, I'm sure that a really thorough programmer such as yourself
> would never forget to insert such a test. But, as was recently
> demonstrated on this mailing list ;-), I'm quite fallible.
> I'm sure there are many other fallible Haskell programmers around.
Don't worry, I'm fallible all r
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
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 techni
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 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
> 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
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 timeout
At 15:02 -0700 98/06/12, Carl R. Witty wrote:
>And I agree with this list, except for infinite loops. How will
>exceptions help make a program robust that otherwise might loop?
There is no general method of finding the non-terminations (the problem
is proved unsolvable, I think), so from that
On 11-Jun-1998, Amr A Sabry <[EMAIL PROTECTED]> wrote:
> 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 Haskell should have the same restriction: it would b
[EMAIL PROTECTED] (Carl R. Witty) writes:
> And I agree with this list, except for infinite loops. How will
> exceptions help make a program robust that otherwise might loop?
Use timeouts - the poor man's solution to the halting problem.
Alastair
Alastair Reid <[EMAIL PROTECTED]> writes:
> But some of us have to write programs that keep working. For example,
> I'm busy hacking on our Robo-Haskell code at the moment - it just isn't
> acceptable for that kind of code to print an error message and halt.
> I remain convinced that:
>
> Ha
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 o
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 th
> 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 Ke
> 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 ac
> Another question: Is "handle" strict in the following argument:
>
> handle :: (IOError -> IO a) -> IO a -> IO a
> ^
> (meaning: will "handle f (return bottom)" be bottom?)
Good question. No, it's not strict in that sense.
Simon
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. (m
> 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 e
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, Simon L Peyton Jones <[EMAIL PROTECTED]> wrote:
|
| Alastair Reid has been very quiet, so I'll pipe up for him.
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 u
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 c
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
Simon L Peyton Jones <[EMAIL PROTECTED]> writes:
> Alastair Reid has been very quiet, [...]
Sorry about that - I just got back from a trip to Germany and am still
trying to catch up on my mail, get the June 98 (bugfix) release of Hugs
out the door, etc.
Exception handling has been high on "Wh
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
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 (
> 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 exc
> * 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
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),
> > x= 1/0 - NaN
(I guess the - is supposed to be a --)
Actually, IEC 559 (a.k.a. IEEE 754, commonly referred to as 'IEEE
floating point') specifies that 1 floating point divided by (positive) 0
shall have the 'continuation value' of *positive infinity*, and (if
trapping is off) one shall recor
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 val
31 matches
Mail list logo
