[Haskell-cafe] ANN: convertible (first release)

[John Goerzen]

wren ng thornton wrote:
> John Goerzen wrote:
>> wren ng thornton wrote:
>>> I once again point out that realToFrac is *wrong* for converting from  
>>> Float or Double.
>>>
>>>     > realToFrac (1/0::Float) ::Double
>>>     3.402823669209385e38
>> Yes, I understand what you are saying and agree with you.  But there
>> is nothing better in the standard library, and I did not feel it was
>> worth adding another dependency to the package simply for the sake of
>> this sort of thing.  People that need it can get it for themselves and
>> write their own instance of Convertible if they wish.
> 
> Then add a wrapper that calls Prelude.isNaN and Prelude.isInfinite in 
> order to guard against these values just like you do for conversion from 
> unbounded types to bounded types.
> 
> Avoiding a trivial dependency is no excuse for avoiding correctness.

"trivial"?

logfloat doesn't appear to even try to work with Hugs.  If I depend on
logfloat, I break compatibility with Hugs.  If I don't, I get behavior
no worse than people are used to from base in the default instances.
Moreover, it adds yet another dep that people have to resolve if they're
not using cabal-install, and yet another library that could break
upstream and wind up breaking my code.

I do ship some helpful default instances with convertible, but the point
of the package is more to provide a standard infrastructure for adding
your own instances, as HDBC does.  I think you are blowing this way out
of proportion.

As for calling isNaN, that may make some sense, though it appears it
would not fix the problem on Hugs, as you recently pointed out.  Though
if isNaN works on a float or double, then we ought to be able to
construct NaN on the other end rather than cause an error.  That's
probably reasonable.

> As Bertram Felgenhauer says, it's not as easy as fixing base; the 
> problem is an error in the Haskell98 specification. The Float and Double 

That doesn't mean you can't add the LogFloat modules to base.  Adding
those modules shouldn't break what Haskell98 mandates, right?

-- John