On Mar 12, 2008, at 11:23 PM, Luke Palmer wrote:
The issue is that exception handling semantics do induce an order of
evaluation for determinacy: if both functions in a composition throw
an exception at some point (say in the 3rd element of a list they're
generating), you need to decide which
On Wed, 12 Mar 2008, Donn Cave wrote:
On Mar 12, 2008, at 2:10 PM, Henning Thielemann wrote:
On Wed, 12 Mar 2008, Donn Cave wrote:
On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote:
On Mar 12, 2008, at 14:17 , Donn Cave wrote:
Sure. It isn't a lot of code, so I subjected it t
On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave <[EMAIL PROTECTED]> wrote:
> Well, the problem inherently requires a certain order of
> evaluation. But if you will just handle pattern match failure
> in the IO monad, then you can write a simple functional
> expression of the problem instead,
>
>
On Mar 12, 2008, at 2:10 PM, Henning Thielemann wrote:
On Wed, 12 Mar 2008, Donn Cave wrote:
On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote:
On Mar 12, 2008, at 14:17 , Donn Cave wrote:
Sure. It isn't a lot of code, so I subjected it to Either-ization
as an experiment, and I
On Wed, 12 Mar 2008, Donn Cave wrote:
On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote:
On Mar 12, 2008, at 14:17 , Donn Cave wrote:
Sure. It isn't a lot of code, so I subjected it to Either-ization
as an experiment, and I did indeed take the monad procedural route.
Monad !=
On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote:
On Mar 12, 2008, at 14:17 , Donn Cave wrote:
Sure. It isn't a lot of code, so I subjected it to Either-ization
as an experiment, and I did indeed take the monad procedural route.
Monad != procedural, unless you insist on do not
On Mar 12, 2008, at 14:17 , Donn Cave wrote:
Sure. It isn't a lot of code, so I subjected it to Either-ization
as an experiment, and I did indeed take the monad procedural route.
Monad != procedural, unless you insist on do notation. Think of it
as composition (it may be easier to use (=<
On Mar 12, 2008, at 6:34 AM, Brandon S. Allbery KF8NH wrote:
On Mar 11, 2008, at 14:27 , Donn Cave wrote:
readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in
LDAPMessage (berInt msgID) (readResponse tag body)
I go on to account for all the LDAP stuff I need in about
On Mar 11, 2008, at 14:27 , Donn Cave wrote:
readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in
LDAPMessage (berInt msgID) (readResponse tag body)
I go on to account for all the LDAP stuff I need in about 60 lines
of that kind of thing, 1/3 of it devoted to declaration
On Tue, 11 Mar 2008, Donn Cave wrote:
On Mar 10, 2008, at 5:48 PM, Jonathan Cast wrote:
On 10 Mar 2008, at 12:37 AM, Donn Cave wrote:
...
An exception is, for me, any state that isn't properly accounted for in
its
immediate context. openFile could return 'Maybe Handle', but it doesn't,
On Mar 10, 2008, at 5:48 PM, Jonathan Cast wrote:
On 10 Mar 2008, at 12:37 AM, Donn Cave wrote:
...
An exception is, for me, any state that isn't properly accounted
for in its
immediate context. openFile could return 'Maybe Handle', but it
doesn't,
so the context demands a Handle or a
Sterling Clover wrote:
> there's no standard way that I know of besides "inspection" to
> determine if code might throw an exception, and this is particularly
> the case with the dreaded lazy IO of prelude functions.
The following old message showed even two ways of doing exactly that
-- in Haske
On 10 Mar 2008, at 12:37 AM, Donn Cave wrote:
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
Errors are programming errors and must be fixed as Denis
explained. Thus
there is no need for a complex system of handling these situations at
run-time. The program error might be unexpect
On Mon, 10 Mar 2008, Donn Cave wrote:
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
How precisely would you handle IndexError if it would be an exception and
not just an error?
Well, to take a hypothetical example ... I have never looked into JPEG
image decoding, but suppose that it
On Mon, Mar 10, 2008 at 7:37 AM, Donn Cave <[EMAIL PROTECTED]> wrote:
>
> On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
>
> >
> > Errors are programming errors and must be fixed as Denis explained.
> > Thus
> > there is no need for a complex system of handling these situations at
> >
On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
Errors are programming errors and must be fixed as Denis explained.
Thus
there is no need for a complex system of handling these situations at
run-time. The program error might be unexpected but it isn't the
fault of
the user or of th
On Sat, 8 Mar 2008, Donn Cave wrote:
> On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote:
>
> > On Sat, 8 Mar 2008, Denis Bueno wrote:
> ...
> >> I am also using STUArray from some time-critical code; however, I
> >> don't deal with ArrayException, or any exceptions for that matter.
> >> What
donn:
>
> On Mar 8, 2008, at 10:54 PM, Don Stewart wrote:
>
> [... replying to my poorly informed rant about exceptions ... ]
>
> >
> >I don't understand this complaint -- you can handle all these with
> >Control.Exception.
> >
> >xmonad catches all these things for example, in user code, to p
On Mar 8, 2008, at 10:54 PM, Don Stewart wrote:
[... replying to my poorly informed rant about exceptions ... ]
I don't understand this complaint -- you can handle all these with
Control.Exception.
xmonad catches all these things for example, in user code, to prevent
poorly written module
On the other hand, there are lots of issues that can be worked on
here, foax! While tools like the one is ndm is working on seem to
offer a way forward, at the moment, there's no standard way that I
know of besides "inspection" to determine if code might throw an
exception, and this is par
On Mar 9, 2008, at 1:54 , Don Stewart wrote:
donn:
This seems to me one of the disappointments of Haskell - not just a
detail that was handled in an awkward way, but a fundamental flaw.
I'm not talking about ArrayException, whatever that is, but the
notion
that errors encountered in functi
donn:
>
> On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote:
>
> >On Sat, 8 Mar 2008, Denis Bueno wrote:
> ...
> >>I am also using STUArray from some time-critical code; however, I
> >>don't deal with ArrayException, or any exceptions for that matter.
> >>What besides an out-of-bounds read or
On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote:
On Sat, 8 Mar 2008, Denis Bueno wrote:
...
I am also using STUArray from some time-critical code; however, I
don't deal with ArrayException, or any exceptions for that matter.
What besides an out-of-bounds read or write might throw an
Arr
On Sat, 8 Mar 2008, Denis Bueno wrote:
On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin <[EMAIL PROTECTED]> wrote:
I'm using STUArray in some of my time critical number
crunching code. I would like to know some way to catch the
exceptions raised in the ST monad, ie. ArrayException.
I am al
"Denis Bueno" <[EMAIL PROTECTED]> writes:
> On Sat, Mar 8, 2008 at 9:54 AM, Xiao-Yong Jin <[EMAIL PROTECTED]> wrote:
>> > ArrayException? If it is out-of-bounds reading or writing, surely
>> > that indicates a bug in your program that you'd rather fix than catch
>> > the exception, no?
>>
>>
On Sat, Mar 8, 2008 at 9:54 AM, Xiao-Yong Jin <[EMAIL PROTECTED]> wrote:
> > ArrayException? If it is out-of-bounds reading or writing, surely
> > that indicates a bug in your program that you'd rather fix than catch
> > the exception, no?
>
> In my case, because I choose a index of the array
"Denis Bueno" <[EMAIL PROTECTED]> writes:
> On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin <[EMAIL PROTECTED]> wrote:
>> I'm using STUArray in some of my time critical number
>> crunching code. I would like to know some way to catch the
>> exceptions raised in the ST monad, ie. ArrayException.
On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin <[EMAIL PROTECTED]> wrote:
> I'm using STUArray in some of my time critical number
> crunching code. I would like to know some way to catch the
> exceptions raised in the ST monad, ie. ArrayException.
I am also using STUArray from some time-critic
Dear list,
I'm using STUArray in some of my time critical number
crunching code. I would like to know some way to catch the
exceptions raised in the ST monad, ie. ArrayException.
Looking through the Control.Exception module, I understand
that those functions can only be used within IO monad. So
29 matches
Mail list logo
