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,
ical of the need for dynamic scope in conventional exception handling,
so I took a shot at this problem, with satisfying results. (I'm not keen on
dynamic typing for that matter, but don't know of a nice way to avoid it.)
Excerpts are below. The full sample code is at
http://pkturner.org/e
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
n?
>That is, closures would handle this just like anything else?
I didn't phrase it well. Denotationally the problem is that, e.g.,
catch (return [1,2,undefined])
(\e -> return [4,5,6]) === return [1,2,undefined]
whereas often (usually!) I'd prefer it be equivalent to
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
> And in Haskell we have catch(Dyn), bracket, and finally.
> > Are these not enough?
>
> We also have Control.Exception.try. :-)
>
> Peter
Yes. Control.Exception.try is defined in terms of Control.Exception.catch:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control.Exception
.
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.
> Doe
Bayley, Alistair writes:
> data SqliteException = SqliteException Int String
> deriving (Typeable)
> catchSqlite :: IO a -> (SqliteException -> IO a) -> IO a
> catchSqlite = catchDyn
> throwSqlite :: SqliteException -> a
> throwSqlite = throwDyn
I, too, think that's a good way to do it.
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
; functionality than OCaml (some might argue it has more),
> but it takes a lot more effort to compose, needing
> to provide a function that returns a function in many cases.
Does it? I'm not convinced... I think it's no more verbose than any other
exception-handling mechanism, but maybe t
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
: [EMAIL PROTECTED]
| Subject: exception handling..
|
|
| Hi,
|
| Is it possible to do/mimic exception handling in Haskell
| using monads.. if
| so can you throw in some pointers on this please..
|
| gmu
| __
| ___
| Get Your
Hi,
Is it possible to do/mimic exception handling in Haskell using monads.. if
so can you throw in some pointers on this please..
gmu
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
today), but they do not add all that much because I use the
type information to pass the functional equivalent of a Java stack
trace.
Please tell me if the operators make sens or whether these operators are
in use elsewhere.
As a matter of course I think that some exception handling functionality
38 matches
Mail list logo
