On 15-Jun-1998, Peter White peter@galois wrote:
On June 15, Fergus Henderson writes
As noted earlier, things like heap overflow, and stack overflow
are different from other kinds of exceptions. They can't be modelled
using the domain-theoretic semantics. Rather, they reflect the
On 15-Jun-1998, Fergus Henderson [EMAIL PROTECTED] wrote:
On 12-Jun-1998, Scott Turner [EMAIL PROTECTED] wrote:
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
On 12-Jun-1998, Scott Turner [EMAIL PROTECTED] wrote:
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.
...
Is this considered a
On 13-Jun-1998, Peter White peter@galois wrote:
I wonder if there is another issue relating potential nondeterminism
of exceptions to the independence of threads. It is supposed to be
the case that two different threads have behavioral independence, so
that an implementation could run the
On Mon, 15 Jun 1998, Fergus Henderson wrote:
P.S. Is there any reason why something like `HyperEval'
isn't built in to Haskell, or at least include in the
Haskell Library report? Is there any implementation-specific
precedent for something like this in say ghc?
Dave Tweed [EMAIL
with ESMTP
id JAA27815; Mon, 15 Jun 1998 09:37:53 -0400
Message-Id: [EMAIL PROTECTED]
To: Dave Tweed [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: Exceptions are too return values!
In-reply-to: Your message of "Mon, 15 Jun 1998 10:03:18 BST."
Pine.SGI.
Here is an input on the exception handling question:
In (pseudo) C++, one can write
try { ... }
catch (A) { if (C) then handle_it else rethrow }
But in a functional language it would be more reasonable to write
if (C) then catch(A) { handle_it }
or something like that, and let
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/0
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)
On Tue, 9 Jun 1998, Mariano Suarez Alvarez wrote:
In a typed language, a function *cannot* be applied to something outside
its domain. That's the whole point!
That represents a certain degree of idealisation though? E.g., sqrt _as a
(single valued) mathematical function_ has domain R^{=0}.
It's nice to have SOME way of handling exceptions, but...
The implementation does not keep sets of exceptional values,
of course. It simply propagates the first one it trips
over to the nearest enclosing handler.
One argument that can be made in favour of a generalised more IEEE-like
On Mon, 8 Jun 1998, S. Alexander Jacobson wrote:
1. it is not logically consistent to treat exceptions as return values
A function cannot do anything but return a value, can it?
For example, suppose that we define a new function:
foo' a b = a + b -- foo' is strict in its arguments
Alex Jacobson:
Ooops, I forgot to remove the "and". Anyway, my point is that
1. it is not logically consistent to treat exceptions as return values
2. as an implementation matter it violates laziness to do so
OK, now I follow. And diagree. ;-) On your second point first:
I'm not sure
13 matches
Mail list logo
