Ketil Malde <[EMAIL PROTECTED]> writes:
> import Prelude hiding (head,(!!),read)
> Any comments?
Here's one: I thought this would make it difficult to have other
imports of Prelude, hiding other pieces of it (e.g. catch, to avoid
ambiguities with Control.Exception.catch)
(Also, the definition o
Ketil Malde <[EMAIL PROTECTED]> writes:
> Unless I'm overlooking something
Which I of course did.
> #define at (let {at (y:_) 0 = y; at (y:ys) n = at ys (n-1); at _ _ = bug "at"
> __FILE__ __LINE__} in \a x -> at a x)
No prize for spotting the bug here.
-kzm
--
If I haven't seen further, it
David Roundy <[EMAIL PROTECTED]> writes:
> Here "bug" is a function that just calls "error" with a little prefix
> explaining that there is a bug in darcs, and would the user please report
> it. Obviously, defining a head here would be just as easy,
Cool! The basic trick is just to inline the a
>No, I don't think so. I only want the bug to be reported
I think preventing the bug using the type system if possible is a good
idea... something that should be encouraged!
>and not a "corner case" that should be "handled".
So if the list depends on user input is not the empty list a corner
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
>> mins = map ((\(x:_)->x).sort)
> maybe what you meant was:
> case sort x of
> (x:_) -> ... do whatever with x ...
> _ -> ... do failure conition ...
No, I don't think so. I only want the bug to be reported, and the
umatched p
Ketil Malde <[EMAIL PROTECTED]> writes:
> Hmm...if I run it through CPP and
> #define HEAD (\x -> if null x then error ("__FILE__:__LINE__") else head x)
> is the __LINE__ resolved at the place of declaration or at the place of usage?
According to the C standard, at the position of /usage/ of
On Tue, Aug 03, 2004 at 12:51:50PM +0200, Ketil Malde wrote:
> Is there any easy way (TH?) to amend these to output the line number
> of the offending caller? It would be a great improvement to see
> something like
>
> Prelude.head : empty list in Foo.hs, line 4711
>
> since programs gen
>mins = map ((\(x:_)->x).sort)
maybe what you meant was:
case sort x of
(x:_) -> ... do whatever with x ...
_ -> ... do failure conition ...
As I said, if you can _guarantee_ non failure I guess head is okay, but the
fact that this thread started with the observati
>Yes, in principle. But that means you still need to write more and
>tedious code to deal with it.
Just because code is tedious does not mean it is not necessary to
handle all corner cases. A robust application does not fail when
given unexpected input.
>Are you going to discard lists in favor o
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
>> As for head, I think it's fine that it throws an error because it is
>> specified to be defined for only non-empty lists.
> But surely it is better to encode this fact in the type system by
> useing a separate type for non-empty lists.
Yes, in princi
David Menendez writes:
> MR K P SCHUPKE writes:
>
> > I would suggest using the type system as I said earlier so:
> >
> > toNonEmptyList :: [a] -> Maybe (NonEmpty a)
> > toNonEmptyList (a0:_) = Just (NonEmpty a)
> > toNonEmptyList _ = Nothing
> >
> > Then redefine head:
> >
> > head :: NonEmpt
On 03-Aug-2004, Alastair Reid <[EMAIL PROTECTED]> wrote:
>
> Another approach is to use a function:
>
> inContext :: String -> a -> a
>
> (implemented using mapException) like this:
>
> inContext "evaluating expression" (eval env e)
>
> to transform an exception of the form:
>
>error
On 03-Aug-2004, Evan LaForge <[EMAIL PROTECTED]> wrote:
>
> In response to the "mysterious head exceptions" thread, isn't there a way to
> compile with profiling and then get the rts to give a traceback on exception?
There is, but it doesn't really work properly, due to
- lazy evaluation
>As for head, I think it's fine that it throws an error because it is
>specified to be defined for only non-empty lists.
But surely it is better to encode this fact in the type system by
useing a separate type for non-empty lists.
>Argh, no! Violating the precondition of head is a bug in the cal
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
> head :: [a] -> Maybe a
> head (a0:_) = Just a0
> head _ = Nothing
Argh, no! Violating the precondition of head is a bug in the caller,
I want it to crash, but I also want to know where. Wrapping it up in
Maybe (or any other error propagation) is not
At 15:28 03/08/04 +0100, MR K P SCHUPKE wrote:
>f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style
Yup, this is how I do it... I never use head!
As a general principle, this bothers me.
In the longer term (i.e. if and when large-scale production Haskell systems
become common), and as
> A lot of programming errors come from failure to correctly validate.
This was actually nicely illustrated in my program: I assumed that digitToInt
accepted '0'..'9' and wanted to rely on it throwing. After puzzling over
out of range errors (other functions expected digitToInt to be in the 0..9
>> Is there any easy way (TH?) to amend these to output the line number
Or use GHC's reifyLocation 'function' in a mapException.
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
>Prelude.head : empty list
>Prelude.read : no parse
> andPrelude.(!!) : index too large
> and so on.
>
> Is there any easy way (TH?) to amend these to output the line number
> of the offending caller?
In a program of any size, I usually avoid using these functions and instead
>f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style
Yup, this is how I do it... I never use head!
I like to pass failures back up to the level where some kind of sensible
error message can be generated. In your example the error is no
better than with 'head' - the point is a Nothin
> Exceptions should only really be used for unpredictcable events, I find
> that the defintion of functions like head is lacking rigor... I would
> prefer to see:
>
> head :: [a] -> Maybe a
> head (a0:_) = Just a0
> head _ = Nothing
In principle, yes, but in practice, that would be silly. You u
>Sometimes the qualification of an error changes while it is propagated.
There was a discussion about this recently (on the ghc list I think)(
The proposed (partial) solution is to use mapException:
mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a
mapExceptionIO f io = Exception.catch
W liście z wto, 03-08-2004, godz. 13:05 +0200, Bjoern Knafla napisał:
> Herb Sutter gave these rules :
>
> An error is any failure that prevents a function from succeeding. Three
> main kind of errors:
[...]
These kinds don't explain much. They don't give a clue which errors
to report by except
Hi - I am just learning Haskell and am far away from exception handling
intricacies. However I just recently read an article of Herb Sutter
about exception handling in C++ with some rules when to use exception
handling - and perhaps these rules might be applicable to Haskell too
(article: "When
Graham Klyne <[EMAIL PROTECTED]> writes:
> 2. I like to distinguish between "expected errors" and "unexpected
> errors". Having been burned in the past by using exceptions (not FP),
> I try to use them only for conditions that are truly unexpected;
> i.e. _exceptional_. Bad input, IMO, is someth
Two observations:
1. When I recently modified the HaXml XML parser, this is one of the
significant changes I made: providing (alterantive) return values based on
Either, so that input errors could be handled by the invoking function,
without forcing it into the IO monad. I guess that's a vote
A lot of programming errors come from failure to correctly validate.
I remember being taught to validate on input _and_ validate when
you use a value. So I would say do both - use maybe for input
functions, and exceptions for when you use a value. You can use
the type system to make this more effic
On Monday 02 August 2004 21:09, Evan LaForge wrote:
> Exceptions are convenient [...]
> [but] an exception will only be thrown when you evaluate t.
>
> So it seems to me that if you are, say, checking input, the options are
> to handle exceptions from the checking code but expect them to come from
Exceptions are convenient in that you can rely on libraries throwing them
instead of prechecking for valid values yourself (for instance, why check
that the argument to Char.digitToInt is valid if digitToInt does so already),
and you don't have to modify a lot of function signatures. Unfortunatel
29 matches
Mail list logo