Duncan Coutts duncan.cou...@worc.ox.ac.uk writes:
Yes, grouping is the one where I most often find the need for head or
partial patterns. The function group produces a list of non-empty lists
but that is not reflected in the type. On the other hand, actually
reflecting it in the type would
On Thu, 26 Mar 2009, wren ng thornton wrote:
Functions like uncons and viewL are nicer (because they're safe), but they
can have overhead because they're unnecessarily complete (e.g. the Maybe
wrapper can be avoided if we know a-priori that Just will be the constructor
used).
If you know,
wren ng thornton wrote:
The type of head should not be [a] - a + Error, it should be (a:[a]) -
a. With the latter type the compiler can ensure the precondition will be
proved before calling head, thus eliminating erroneous calls.
Yes, but you know and I know that's not haskell.
I'm talking
On Fri, 2009-03-27 at 12:26 +0100, Henning Thielemann wrote:
On Thu, 26 Mar 2009, wren ng thornton wrote:
Functions like uncons and viewL are nicer (because they're safe), but they
can have overhead because they're unnecessarily complete (e.g. the Maybe
wrapper can be avoided if we know
wren ng thornton wrote:
I have long been disappointed by a number of `error`s which shouldn't
be. For example, the fact that `head` and `div` are not total strikes me
as a (solvable) weakness of type checking, rather than things that
should occur as programmer errors/exceptions at runtime. The
On Thu, 26 Mar 2009, Jules Bean wrote:
There are programming styles which avoid using 'head'. You are free to use
those if you don't like it. I myself am content to use 'head' on lists which
I know are guaranteed to be non-empty.
Since I became aware that viewl (Data.Sequence) and uncons
On Wed, 25 Mar 2009, wren ng thornton wrote:
Extensible exceptions are impressive, but the existence of exceptions
outside of type annotations says something about purity.
Did I already promote explicit-exceptions package? :-)
___
Haskell-Cafe
[mailto:haskell-cafe-boun...@haskell.org]
Im Auftrag von Henning Thielemann
Gesendet: Dienstag, 24. März 2009 21:34
An: Xiao-Yong Jin
Cc: haskell-cafe@haskell.org
Betreff: Re: Exception handling in numeric computations (was Re:
[Haskell-cafe]Use unsafePerformIO to catch Exception?)
On Tue, 24
Jules Bean wrote:
wren ng thornton wrote:
I have long been disappointed by a number of `error`s which shouldn't
be. For example, the fact that `head` and `div` are not total strikes
me as a (solvable) weakness of type checking, rather than things that
should occur as programmer
On Thu, Mar 26, 2009 at 5:23 PM, wren ng thornton w...@freegeek.org wrote:
Jules Bean wrote:
wren ng thornton wrote:
I have long been disappointed by a number of `error`s which shouldn't
be. For example, the fact that `head` and `div` are not total strikes me
as a (solvable) weakness of
On Thu, Mar 26, 2009 at 6:42 PM, Alexander Dunlap
alexander.dun...@gmail.com wrote:
On Thu, Mar 26, 2009 at 5:23 PM, wren ng thornton w...@freegeek.org
wrote:
It's a static error, detectable statically, and yet it's deferred to the
runtime. I'd much rather the compiler catch my errors than
Alexander Dunlap wrote:
wren ng thornton wrote:
Jules Bean wrote:
head uses error in precisely the correct, intended fashion.
head has a precondition (only call on non-empty lists)
And that is *exactly* my complaint: the precondition is not verified by the
compiler. Therefore it does
Luke Palmer wrote:
Alexander Dunlap wrote:
Ultimately, it's not detectable statically, is it? Consider
import Control.Applicative
main = do
f - lines $ readFile foobar
print (head (head f))
You can't know whether or not head will crash until runtime.
Static checkers are usually
Quoth Duncan Coutts duncan.cou...@worc.ox.ac.uk:
You must not do this. It breaks the semantics of the language.
Other people have given practical reasons why you should not but a
theoretical reason is that you've defined a non-continuous function.
That is impossible in the normal semantics
Donn Cave wrote:
Could you elaborate a little, in what sense are we (?) relying on it?
I actually can't find any responses that make a case against it on a
really practical level - I mean, it seems to be taken for granted that
it will work as intended, and we're down to whether we ought to have
On Tue, 2009-03-24 at 23:13 -0700, Donn Cave wrote:
Quoth Duncan Coutts duncan.cou...@worc.ox.ac.uk:
You must not do this. It breaks the semantics of the language.
Other people have given practical reasons why you should not but a
theoretical reason is that you've defined a
Jonathan Cast jonathancc...@fastmail.fm writes:
On Tue, 2009-03-24 at 23:13 -0700, Donn Cave wrote:
Quoth Duncan Coutts duncan.cou...@worc.ox.ac.uk:
You must not do this. It breaks the semantics of the language.
Other people have given practical reasons why you should not but a
Some examples of what might happen:
If you have more than one possible exception in your code, you don't
know which one you will get.
It can vary between compilers, optimization levels, program runs, or
even evaluating the same expression within one program.
If you have code that have both an
On Wed, 2009-03-25 at 07:39 -0400, Xiao-Yong Jin wrote:
Jonathan Cast jonathancc...@fastmail.fm writes:
On Tue, 2009-03-24 at 23:13 -0700, Donn Cave wrote:
Quoth Duncan Coutts duncan.cou...@worc.ox.ac.uk:
You must not do this. It breaks the semantics of the language.
Other
Quoth Lennart Augustsson lenn...@augustsson.net:
Some examples of what might happen:
OK, these are interesting phenomena. From a practical point of view,
though, I could see someone weighing the potential costs and benefits
of a exception handler outside IO like this, and these effects might
On Wed, 2009-03-25 at 09:15 -0700, Donn Cave wrote:
Quoth Lennart Augustsson lenn...@augustsson.net:
Some examples of what might happen:
OK, these are interesting phenomena. From a practical point of view,
though, I could see someone weighing the potential costs and benefits
of a
If you think non-determinstic programs are acceptable, then you can
use unsafePerformIO this way.
But future versions of compilers may make them even more
unpredictable, so beware.
I think that if the exception handler does not look at exactly what
exception was thrown, then the program will just
Quoth Jonathan Cast jonathancc...@fastmail.fm:
On Wed, 2009-03-25 at 09:15 -0700, Donn Cave wrote:
OK, these are interesting phenomena. From a practical point of view,
though, I could see someone weighing the potential costs and benefits
of a exception handler outside IO like this, and these
Hi Duncan and all,
On Wed, Mar 25, 2009 at 3:52 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
On Mon, 2009-03-23 at 08:11 -0400, Xiao-Yong Jin wrote:
tryArith :: a - Either ArithException a
tryArith = unsafePerformIO . try . evaluate
You must not do this. It breaks the semantics of
On Wed, 2009-03-25 at 10:00 -0700, Donn Cave wrote:
Quoth Jonathan Cast jonathancc...@fastmail.fm:
On Wed, 2009-03-25 at 09:15 -0700, Donn Cave wrote:
OK, these are interesting phenomena. From a practical point of view,
though, I could see someone weighing the potential costs and
Quoth Jonathan Cast jonathancc...@fastmail.fm:
On Wed, 2009-03-25 at 10:00 -0700, Donn Cave wrote:
So I thought it would be interesting to explore statements like you
must not do this, and pure Haskell is not allowed to be
non-deterministic, in terms of practical effects. No one would
make
On Wed, 25 Mar 2009, Jonathan Cast wrote:
On Wed, 2009-03-25 at 07:39 -0400, Xiao-Yong Jin wrote:
Could you elaborate more about why this kind of breakage
wouldn't happen if 'try' is used in an IO monad as intended?
It would. But it would happen in IO, which is allowed to be
On Wed, 2009-03-25 at 22:32 +0100, Henning Thielemann wrote:
On Wed, 25 Mar 2009, Jonathan Cast wrote:
On Wed, 2009-03-25 at 07:39 -0400, Xiao-Yong Jin wrote:
Could you elaborate more about why this kind of breakage
wouldn't happen if 'try' is used in an IO monad as intended?
It
Henning Thielemann wrote:
Jonathan Cast wrote:
Xiao-Yong Jin wrote:
Could you elaborate more about why this kind of breakage
wouldn't happen if 'try' is used in an IO monad as intended?
It would. But it would happen in IO, which is allowed to be
non-deterministic. Pure Haskell is not
On Wed, 2009-03-25 at 18:14 +0100, Benja Fallenstein wrote:
On Wed, Mar 25, 2009 at 3:52 AM, Duncan Coutts
Of course your tryArith only tests for certain kinds of _|_ value, but
in principle the problem is the same.
That's not *quite* how the semantics of Haskell exceptions are
defined,
On Thu, Mar 26, 2009 at 2:40 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
I was not being precise when I said tests for _|_. As you point out,
the semantics of imprecise exceptions distinguishes exceptions from
bottom, however pure code cannot make that distinction and so that's why
I
Henning Thielemann lemm...@henning-thielemann.de writes:
Try to never use exception handling for catching programming errors!
Division by zero is undefined, thus a programming error when it
occurs.
http://www.haskell.org/haskellwiki/Error
http://www.haskell.org/haskellwiki/Exception
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xiao-Yong Jin wrote:
| The problem is that there will be many functions using such
| a function to invert a matrix, making this inversion
| function return Either/Maybe or packing it in a monad is
| just a big headache.
I disagree. If you try to
On Tue, Mar 24, 2009 at 1:27 PM, Xiao-Yong Jin xj2...@columbia.edu wrote:
Henning Thielemann lemm...@henning-thielemann.de writes:
Try to never use exception handling for catching programming errors!
Division by zero is undefined, thus a programming error when it
occurs.
On Tue, 24 Mar 2009, Xiao-Yong Jin wrote:
invMat :: Matrix - Matrix
You won't be able to invert all the matrix, mathematically.
And computationally, even a larger set of matrix might fail
to be inverted because of the finite precision. It is
relatively easier and more efficient to spot such
On Tue, 24 Mar 2009, Daniel Yokomizo wrote:
If we try the other approach, we need to express the totality of
invMat by restricting its domain, so we can add, for example, a
phantom type to Matrix to signal it is invertible. As you need to
construct the Matrix before trying to invert it you can
On Mon, 2009-03-23 at 08:11 -0400, Xiao-Yong Jin wrote:
Hi,
I just feel it is not comfortable to deal with exceptions
only within IO monad, so I defined
tryArith :: a - Either ArithException a
tryArith = unsafePerformIO . try . evaluate
You must not do this. It breaks the semantics of
Hi,
I just feel it is not comfortable to deal with exceptions
only within IO monad, so I defined
tryArith :: a - Either ArithException a
tryArith = unsafePerformIO . try . evaluate
and it works quite good as
map (tryArith . (div 5)) [2,1,0,5]
evaluates to
[Right 2,Right 5,Left divide by
On Mon, 23 Mar 2009, Xiao-Yong Jin wrote:
Hi,
I just feel it is not comfortable to deal with exceptions
only within IO monad, so I defined
tryArith :: a - Either ArithException a
tryArith = unsafePerformIO . try . evaluate
and it works quite good as
map (tryArith . (div 5)) [2,1,0,5]
Xiao-Yong Jin wrote:
Hi,
I just feel it is not comfortable to deal with exceptions
only within IO monad, so I defined
tryArith :: a - Either ArithException a
tryArith = unsafePerformIO . try . evaluate
[...]
However, I guess unsafePerformIO definitely has a reason for
its name. As I read
40 matches
Mail list logo
