Last week John Goerzen asked about exceptions in Haskell. I responded with
some code that supports a hierarchy of exception types. Jules Bean reacted
that "the internal implementation with fromDynamic doesn't seem pretty
though".
Although dynamic types reflect the common implementation of exce
Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have a function like
mkCatchJu
Jules Bean wrote:
By the same token, you can just stick the function strangeReadFile ::
FilePath -> String into the language. As long as it is memoized, always
returning the same value, it doesn't break beta-reduction. I call it
'strange' because the time that the file is actually read is not
g
Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have a function like
mkCatchJu
On 25 Nov 2004, at 19:24, Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
> As I'm sure you have gathered from all the answers you can't have the
> latter and keep Haskell pure. But there is an interesting alternative
> (at least theoretically). You could have a function like
>
> mkCatchJust :: IO ((E
John Goerzen wrote:
So why do we have:
catchJust :: (Exception -> Maybe b) -> IO a -> (b -> IO a) -> IO a
instead of:
catchJust :: (Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there
Gosh, I shouldn't post to mailing lists after midnight. Please excuse my
needless explanations. I didn't understand your answer at first.
Cheers,
Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
On Thursday 25 November 2004 00:29, Scott Turner wrote:
> John Goerzen wrote:
> > I note, though, that "making an Either into a Monad" doesn't do
> > anything to deal with asynchronous exceptions.
>
> [ snip]
>
> > I was referring to exceptions generated by things such as signals,
> > interrupts, c
John Goerzen wrote:
> I note, though, that "making an Either into a Monad" doesn't do
> anything to deal with asynchronous exceptions.
[ snip]
> I was referring to exceptions generated by things such as signals,
> interrupts, certain network errors, stack problems, etc.
How would you like asynchro
On Wed, Nov 24, 2004 at 07:14:28PM +, Jules Bean wrote:
>
> On 24 Nov 2004, at 18:28, John Goerzen wrote:
>
> >I note, though, that "making an Either into a Monad" doesn't do
> >anything
> >to deal with asynchronous exceptions.
> >
[ snip]
> If that isn't what you meant by asynchronous exc
On 24 Nov 2004, at 19:16, Scott Turner wrote:
Each error type is an instance of Hierarchical, so that its errors may
be
considered part of a larger category of errors. In the instance
definition,
'parent' specifies how the error appears if it is caught by a handler
expecting then next more gener
On 2004 November 24 Wednesday 13:12, Jules Bean wrote:
> On 24 Nov 2004, at 16:21, Scott Turner wrote:
> > On 2004 November 23 Tuesday 10:51, John Goerzen wrote:
> > The way to deal with those kinds of details is to use Either in a
> > monad.
> Ok, I glanced through your code, and you seem to be
On 24 Nov 2004, at 18:28, John Goerzen wrote:
I note, though, that "making an Either into a Monad" doesn't do
anything
to deal with asynchronous exceptions.
We may be talking at cross purposes here. If, by 'asynchronous
exceptions' you mean that exceptions may lurk arbitrarily deeply within
use
On Wed, Nov 24, 2004 at 06:12:27PM +, Jules Bean wrote:
> Ok, I glanced through your code, and you seem to be reimplementing many
> of the ideas in the MonadError class, which also makes Either into a
> Monad.
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/
> Control.Monad
On 24 Nov 2004, at 16:21, Scott Turner wrote:
On 2004 November 23 Tuesday 10:51, John Goerzen wrote:
The way to deal with those kinds of details is to use Either in a
monad. I'm
skeptical of the need for dynamic scope in conventional exception
handling,
so I took a shot at this problem, with s
On 2004 November 23 Tuesday 10:51, John Goerzen wrote:
> > for pure functions, returning Either Error Result is the way to go.
> One example: I've written an FTP client library. For every operation,
> there are several possible outcomes... mainly: success, low-level
> network error, or server err
On Tue, 23 Nov 2004, John Goerzen wrote:
(snip)
> I've been using Haskell for 1-2 months now, and feel fairly comfortable
(snip)
> catchJust :: (Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a
(snip)
Yes, this was one of the first things that bothered me, too, when I
started actually writi
Marcin 'Qrczak' Kowalczyk wrote:
>What is
> exceptionToMaybe (f 0 + error "x")
>where
> f x = f x
>?
I guess that answers my question. :-)
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> The intended semantics is
>
> / Nothing if x is a set of exceptions
> exceptionToMaybe x = | _|_ if x is _|_
> \ Just xotherwise
What is
exceptionToMaybe (f 0 + error "x")
where
John Goerzen wrote:
Python can work that way, but also adds another feature:
try:
blah
moreblah
finally:
foo
And in Haskell we have catch(Dyn), bracket, and finally. Are these not
enough?
I hadn't been aware of finally. That does seem to help.
One of the things I like about exceptions in
John Goerzen wrote:
>On Tue, Nov 23, 2004 at 05:20:19PM +, Ben Rudiak-Gould wrote:
>
>>In any case, mapException is pure, and it's good enough for most of
the cases where one might want to catch exceptions outside the IO monad.
>
>Well, I'm maving trouble wrapping my head around how I could us
On Tue, Nov 23, 2004 at 05:20:19PM +, Ben Rudiak-Gould wrote:
> >So what am I missing here?
>
> myfunc might raise more than one exception. For example,
>
>myfunc = error "x" + error "y"
Gotcha. That's the piece I was missing!
[ snip ]
>
> those I catch. If each particular implementa
On 23 Nov 2004, at 15:51, John Goerzen wrote:
On Tue, Nov 23, 2004 at 04:30:21PM +, Keean Schupke wrote:
I am sure this discussion has happened before, but I think for pure
functions, returning Either Error Result is the way to go.
That's certainly possible, but extremely tedious.
It sounds to
John Goerzen wrote:
>myfunc :: String -> Int
>
>This does some sort of string parsing and returns an Int. Or it may
>raise an exception if it couldn't parse the string. But it would do
>that every time.
>
>Now, let's say we have a non-IO catchJust. Of course, if we never need
>the value, we neve
I, too, had a gripe about this, and was pointed to an excellent paper that
explains all:
A Semantics for Imprecise Exceptions (1999)
Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, Fergus
Henderson
SIGPLAN Conference on Programming Language Design and Implementation
http://c
On Tue, Nov 23, 2004 at 03:43:09PM -, Bayley, Alistair wrote:
Thanks for your thoughtful reply. Let me try to expand on it a little
bit.
> Here's how I create "custom" exceptions; it doesn't seem onerous to me, but
> then I have a high tolerance for some kinds of coding pain:
>
> > data Sql
On Tue, Nov 23, 2004 at 04:30:21PM +, Keean Schupke wrote:
> I am sure this discussion has happened before, but I think for pure
> functions, returning Either Error Result is the way to go.
That's certainly possible, but extremely tedious.
One example: I've written an FTP client library. For
> From: John Goerzen [mailto:[EMAIL PROTECTED]
>
> My other choice is to use Dynamic for my
> exceptions, but that makes it even more
> difficult to catch and handle
Here's how I create "custom" exceptions; it doesn't seem onerous to me, but
then I have a high tolerance for some kinds of coding
I am sure this discussion has happened before, but I think for pure
functions, returning Either Error Result is the way to go.
Keean.
John Goerzen wrote:
On Tue, Nov 23, 2004 at 04:12:52PM +0100, Johannes Waldmann wrote:
The other annoying thing is forcing it to run in the IO monad.
__
On Tue, Nov 23, 2004 at 04:12:52PM +0100, Johannes Waldmann wrote:
>
> >The other annoying thing is forcing it to run in the IO monad.
>
> necessarily so, since Haskell has non-strict semantics
> so it's not so clear when an exception is actually raised
> (you might have left the block that te
The other annoying thing is forcing it to run in the IO monad.
necessarily so, since Haskell has non-strict semantics
so it's not so clear when an exception is actually raised
(you might have left the block that textually contained the offending
expression , and the exception handler, a long t
Hi everyone,
I've been using Haskell for 1-2 months now, and feel fairly comfortable
with the language. However, my #1 gripe is the difficulty of working
with exceptions. I have two main complaints: difficulty of defining
custom exceptions, and difficulty of handling exceptions.
I've been worki
33 matches
Mail list logo
