At 14:40 1998-06-10 +0100, you wrote:
>Here's a reasonable design for exceptions in Haskell:
>* handle :: (String -> IO a) -> IO a -> IO a
You probably realized more quickly than I how this
can leak exceptions. What I mean is
main = do quotient <- handle (const (return 0)) (return (0 / 0)
At 17:46 +0200 98/06/12, Jerzy Karczmarczuk wrote:
> a. The code should be as short as possible. Inserting specific code which
>treats infinities in many places is not a good idea.
> b. The infinities (and NaNs) *should* bomb, and never propagate.
>So, I agree with Hans Aberg that in such a ca
[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
Fergus Henderson:
> >Infinities are probably best treated as a seperate issue.
> >That is, infinities should not correspond to exceptions.
> >If you have a type which supports infinities, then 1/0 should return
> >infinity, not raise an exception.
Hans Aberg responds:
> I think it is best to l
At 10:50 +1000 98/06/12, Fergus Henderson wrote:
>Infinities are probably best treated as a seperate issue.
>That is, infinities should not correspond to exceptions.
>If you have a type which supports infinities, then 1/0 should return
>infinity, not raise an exception. Conversely, if you want 1/
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
Laziness appears to have a wierd interaction with IO.
According to the docs, you should add two numbers from the user like this:
> main = do
> hSetBuffering stdout NoBuffering
> putStr "Enter an integer: "
> x1 <- readNum
> putStr "Enter
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
On 11-Jun-1998, Karlsson Kent - keka <[EMAIL PROTECTED]> wrote:
> ...
> > Then the code which draws the graph just needs to do some pattern
> > matching on the `MaybeException y' at the appropriate place:
> >
> > plot_point x (OK y) = ...
> > plot_point x (GotException exception) = ...
>
10 matches
Mail list logo
