[Haskell-cafe] Re: Why purely in haskell?

[jerzy.karczmarczuk at info.unicaen.fr]

Cristian Baboi writes after my long political speech on numerics: 

> Well, Haskell has this "referential transparency" thing which say that a  
> function is a function and you will never be able to build anything else  
> :-)

What do you want to say/claim/suggest/propose/deny??
All these speculations about NaN==NaN, and other disgraceful exceptions
don't convey anything which would really break the referential transparency,
unless you outlaw yourself. 

Travesting a US military saying:
 If 'em things are not comparable, don't! 

We can formalize this attitude, e.g. by extending/modifying the Num (and
the Eq and Ord) classes to take into account the specificity of the
non-standard arithmetic, but in general this contains plenty of traps.
It will be eventually done, but perhaps not tomorrow... 

Ketil Malde reacts to: 

>> The bombing of NaN *might* be a profound compilation option, but for
>> people who really do numerical work, this is a blessing NOT to have
>> it.
> 
> I don't understand this.  Are you worried users will edit the
> language pragmas in your code, and complain about NaN errors?

I do not worry about anything. I signal that the philosophy of crashing
the program as soon as an exceptional number is created (or even used),
is not the only one possible. 

> Back when I *was* using the abbreviation FP for 'Floatin Point', I
> often got NaNs due to programming errors.  Given the NaN's nature of
> contaminating subsequent results, getting an exception at the first
> occurrence would aid in tracking it down. 
> 
>> - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful
>> for many purposes.
> 
> ...and ditto for this.  The usefulness of one case in no way justifies
> sabotagin all other cases.

As I said, the exceptional treatment of exceptional values might be
a compilation option, as it was in some Fortrans I used long time ago.
You want your programs to react histerically to all difficulties in math,
since you are afraid of propagating NaNs, etc. And *then* you will have to
sit down and correct your code. If there is no exception, your program
may run happily, and produce rubbish, yes? 

I am more conservative. If you are afraid of rubbish, protect your code
by appropriate checks *before* the errors occur. What you call a "sabotage"
I call the programmers negligence. You say that the usage of NaN as "empty"
is a <<poor man's way of spelling "Maybe Double">>. I presume you want
to say "Nothing". In a sense yes, but not "poor man". It is a way of
admitting that we have a hidden extended type, Nums, and other stuff, such
as NaNs and infinities. Floating-point numbers seem not to be a *one*
pure, primitive type, but a variant one. The problem is that this new type
values may come out of computations on normal values, so the static type
system of Haskell *in its actual shape* seems to be a bit too weak. 

Instead of making a mess with the existing structures, please, propose
a non-standard Num class, and the appropriate instancing, which distinguish
between normal, and anormal numbers. Be free to bomb, or to react silently
to exceptional values. 

The difference between you (and/or Wolfgang J.) and myself is that I enjoy
more my freedom, even if I have to pay with a little more work. You want
to enforce rigid reactions of the system. You should be free to do it on
*your* machine, not on mine. 


Jerzy Karczmarczuk