Isaac Dupree isaacdupree at charter.net
Wed Sep 12 10:37:02 EDT 2007

```Philip K.F. Hölzenspies wrote:
> The GHC extensions are used, however,
> because of laziness; i.e. automatic derivation of Enum, Num,
> Fractional, Real and RealFrac. Without the GHC extensions, only Eq and
> me know, because I would prefer a compiler independent solution as
> well.

Thank you for reminding me.  You can preferably use {-# LANGUAGE
GeneralizedNewtypeDeriving #-} instead of {-# OPTIONS -fglasgow-exts
#-}, to just enable the needed extension, although only GHC implements
it currently....  Or, you can explicitly write out each instance in the
very straightforward way, which is portable (though a bit annoying and
inefficient).  Or, I think there are tools that can automatically write
such instances for you?

> [...]
>  At that time I could either have my own simplifier and
> approximator, or I could link to other tools (maple, gnu something?).
>
> The idea was stalled, because I only use this for toy problems ;) If
> someone feels inspired, feel free to take this module and rework. I'm
> also open for suggestions on how to do this myself in case I ever
> un-stall this ;)

That is *a lot* more complicated. Beware of non-termination. I don't
think every equality, every exactness, is observable (not sure whether a
Num type like that offers the full power of the real numbers - if it
does, then you have a turing-complete problem.)

Whereas, the present inexactness means that the numerator and
denominator don't tend to get so big that the computations are really
slow.  (If MPFR could be used in Haskell, one could choose the desired
precision rather than using whatever Double gives, I suppose)

Making the type be "data" with fields Rational as well as whether it's
exact, could be done (though I'm not entirely satisfied with, nor
interested in, the "exact" concept, so it's just an idea).  Then you
would not be able to use generalized newtype deriving, so you wouldn't ^_^

Isaac
```