[Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms

[Casey McCann]

On Thu, Apr 8, 2010 at 2:09 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Template Haskell can help dull the pain, but the result seems hardly idiomatic.

Well, since this is dealing with types and type classes, much of the
required boilerplate could also be straightforwardly derived in full
generality using type-level metaprogramming techniques rather than TH,
but the outcome of that would likely be even less tasteful, in the
sense of "so many UndecidableInstances that you won't be able to
scratch your nose without running into the Halting Problem". With a
bit of finesse, though, I suspect the result could allow users of the
library to avoid both boilerplate and unnerving GHC extensions.
Compatibility with Prelude classes could probably also be solved this
way.

Still, probably not terribly appealing to most folks.

> The amount of code to define a new Field-like object can baloon to well over a hundred lines, and in the above I didn't even address how to work with near-field-like concepts like Fields and Doubles, which don't support all of the laws but which have the same feel.

I'm somewhat uncomfortable as it is with equivocating between "true"
mathematical objects and hand-wavy approximations that have hardware
support. Seriously, floating point so-called "numbers" don't even have
reflexive equality! If anything, it seems like there might be value in
chopping the numeric types apart into "fast number-crunchy types" and
"types with nice algebraic properties", and then enhancing each with
relevant functionality.

- C.