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 principle.
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 of
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 observation
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 generally
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 the
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 pattern
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
case
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 actual
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 is by
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 of
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
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 something that
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
W licie 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 exceptions
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 use
head
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 Nothing
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
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
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
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 a
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
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 :: NonEmpty a - a
head
22 matches
Mail list logo
