On Sun, 15 Jun 2008, Andrew Coppin wrote:
Henning Thielemann wrote:
I think it is another instance of mixing up errors and exceptions (you know
the haskellwiki pages ...)
Since an 'error' marks a programming error (which should never occur) it
would not hurt the program if all 'error's are replaced by 'undefined', an
illegal memory access or any other misbehaviour. So 'error' is exactly what
you propose as IMPOSSIBLE pragma. A compiler option for replacing all
'error's by nops would do want you want.
OK, so suppose I write a module that contains a function that accepts a
number parameter, and that parameter must be greater than 2. I have no
control over what value users of the library pass to my function. Suppose
some client calls my function with 1 as an argument - is that an error, or an
exception?
It's an error, like 'head []' is an error. You must document the condition
(argument > 2), unfortunately Haskell's type system does not allow to
state such conditiions conveniently, and then it's the caller's
responsibility to ensure that the argument is greater than 2.
I like to distinguish between two kinds of users. (Are there common names
for them?) The (consumer) user communicates with your program via an
interface you provide: A GUI, the command line, a network. The user may
even not know, that the program is written in Haskell. Everything this
user makes wrong is an exception. You cannot forbid the user to make
something wrong. The other kind of users are programmers, who call
functions of your library. This interface is especially fast but in order
to get the efficiency you can expect some cooperation by the programmer.
E.g. the programmer of your library must ensure that the argument is
always greater than 2. Otherwise _he_ has done an _error_.
However if he writes a program which lets the user enter the number in a
GUI dialog which is then passed to your library, then he must check the
number before forwarding it, because the user can do wrong things. If the
user enters '1' this is an _exception_. If the programmer does not reject
this input it is an error.
On the other hand, suppose I write the same function, but now it's not
exported. So the only code that can possibly call this function is my own
code. So I can [theoretically] guarantee it will never be called with the
"wrong" argument [assuming the code I write isn't defective].
As far as I can tell, there's no way of making this distinction in Haskell
code. You'd use "error" in both cases - or if you're feeling brave, remove it
in the second case and hope you're right. I'm just saying it would be nice to
be able to keep it in the code for maintainability's sake, but not have the
runtime penalty for it once you're "sure" your code is safe.
In theory you could remove 'error' in both cases, because in theory
neither you nor the library user makes mistakes. In practice you better
leave the error, because both of you actually make mistakes.
It looks like Don's "assert" thing might be able to do this. [I had no idea
this existed by the way...]
As far as I understand, 'assert' is a wrapper to 'error' which also
determines the source code location without using the C preprocessor. Is
this correct?
Hmm, this gives me a new idea for a feature request - how about a function
that evaluates to the source code line number it was called from? ;-)
Would be also nice for a "single stepper", which shows at which places in
the source code things are currently evaluated.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
