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

[Edward Kmett]

On Thu, Apr 8, 2010 at 3:25 PM, Casey McCann <syntaxglitch at gmail.com> wrote:

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


Unfortunately the type level metaprogramming approach doesn't really yield
something that has an idiomatic usage pattern and would still rely on
extensions, since you'd need Type Families and/or
MPTCs/Fundeps/UndecidableInstances/IncoherentInstances.

A TH solution needn't be that bad with template haskell and quasiquotation:

[$field ''MyField|
    (+) = ...
    (*) = ...
    negate = .. |]

You just construct the tower of instances needed and bake in a bunch of
machinery to precalculate the appropriate defaults and derived members. This
has the advantage that if the numerical tower is refactored to add another
level, then the client side code doesn't break.


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


I agree they should be separated. In my previous implementation of these I
had built up a "Pseudo-" prefixed numerical tower for when you couldn't rely
on the laws to apply, and a newtype wrapper that let you coerce then into
something for which you claim the laws locally apply. What I meant was that
I hadn't bothered to include the Pseudo-prefixed variants on each of the
classes, which bloats the example even further.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100408/967d648a/attachment.html