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

wren ng thornton wren at freegeek.org
Thu Jan 29 00:10:29 EST 2009


John Goerzen wrote:
> 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.
> > >
> > > 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"?

It only depends on base (the new smaller one even) and common language 
extensions which are supported by Hugs (CPP, FlexibleContexts, 
OverlappingInstances, FlexibleInstances, UndecidableInstances, 
MultiParamTypeClasses). Granted, Yhc and nhc98 are out of the running 
because of MPTCs.


> logfloat doesn't appear to even try to work with Hugs.

Works fine for me...

$> hugs -98 +o -F'cpp -P' Data/Number/LogFloat.hs
__   __ __  __  ____   ___      _________________________________________
||   || ||  || ||  || ||__      Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__||  __||     Copyright (c) 1994-2005
||---||         ___||           World Wide Web: http://haskell.org/hugs
||   ||                         Bugs: http://hackage.haskell.org/trac/hugs
||   || Version: September 2006 _________________________________________

Hugs mode: Restart with command line option +98 for Haskell 98 mode

Type :? for help
Data.Number.LogFloat>



Granted, I just found some bugs due to bugs in Hugs regarding 
exceptional values. These will be fixed in the next release.


> 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.

I think you undervalue the importance of correct code. Many programmers 
beside myself use Haskell because it guarantees more-correct code than 
other languages. Correctness is expecially important for "standard 
infrastructure". Not providing instances is better than providing 
incorrect instances. Given all the other instances for Int, Integer, 
etc, it's not tenable to offer the advice that those who do care about 
correctness should avoid Data.Convertible.Instances.Num.


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

The LogFloat module relies on Transfinite which in turn relies on 
PartialOrd. In particular the corrected versions of log, realToFrac, 
isNaN, and isInfinite are all used to ensure correctness of LogFloat. 
The RealToFrac class in Transfinite uses MPTCs which are non-Haskell98 
and therefore restricts it to GHC or Hugs. Since base is used by nhc98 
and other Haskell compilers, that means RealToFrac and LogFloat are not 
an option.

In theory I could replace the type class with a polymorphic function 
using the default instance's definition, and use rewrite rules to 
replace that function with the efficient versions at particular types. 
In some ways this would be nicer (no overlapping instances here, though 
PartialOrd still uses them). But in other ways it's less nice since it 
just moves the problem elsewhere; namely, there are other Real types 
which may have additional values that cannot be expressed in Rational. 
The type class allows resolving this by testing for these values or 
placing additional constraints on the types, whereas the polymorphic 
function ---though more correct than the Prelude's--- would still be 
incorrect since the library cannot know about all such types.

-- 
Live well,
~wren


More information about the Haskell-Cafe mailing list