[Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)

[Bjorn Buckwalter]

Alfonso Acosta <alfonso.acosta <at> gmail.com> writes:

> Actually it would maybe be better to create common high-level
> interface that could include unary, binary and decimal arithmetic so
> that the library could be easily reused in other projects (people like
> Bjorn, seem to be using the unary implementation). I don't know if it
> would be feasible though.

My reason for going with unary implementation was that it seemed
to be the easiest and less tedious to implement. But is sure does
make the error messages less friendly. It also limits the magnitude
of the numbers quite severely unless one bumps up the type checker
stack size. From the source code:

"The practical size of the NumTypes is limited by the type checker
stack. If the NumTypes grow too large (which can happen quickly
with multiplication) an error message similar to the following will
be emitted:

    Context reduction stack overflow; size = 20 
    Use -fcontext-stack=N to increase stack size to N

This situation could concievably be mitigated significantly by using
e.g. a binary representation of integers rather than Peano numbers."

For my use (keeping track of physical dimensions) this hasn't been
a problem.

If Naturals had been sufficient for me I wouldn't have done my own
implementation (I'm unaware of any other implementation of Integers).
And there is certainly a lot of value to the clearer error messages
from a decimal representation.

Concerning whether or not there is any value in being able to change
the representation of the type- level naturals in your library, my
guess is that the value wouldn't be all that great. As I mentioned
I use my implementation for tracking physical dimensions and HList's
HNats for constraining vector dimensions but this isn't a problem
since I cannot conceive of any reason why I would want to intermix
the two. Of course, other usage scenarios exist where there would
be a desire to intermix the vector dimensions with something else...?

So sure, if you can abstract the representation away by all means
do it. But I wouldn't go out of my way or impair the rest of the
library to achieve this.

Hope this helps,
Bjorn