[Haskell-cafe] Documenting the impossible

Henning Thielemann lemming at henning-thielemann.de
Sun Jun 15 15:37:21 EDT 2008

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.

More information about the Haskell-Cafe mailing list