[Haskell-cafe] Re: Implementing fixed-sized vectors (using
datatype algebra?)
Alfonso Acosta
alfonso.acosta at gmail.com
Fri Feb 1 07:00:05 EST 2008
On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz:
> > Look at
> >
> > http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf
>
> This is essentially what I had in mind. While Oleg's implementation needs
> a "thrusted core", the GADT solution doesn't.
True. However using GADTs doesn't allow to internally make use of
Arrays, which (tell me if I'm wrong) are likely to be faster than the
naive GADT implementation.
Actually the GADT implementation you proposed fits nicely with the
Vector definition already used in my EDSL (it is isomorphic actually),
but efficiency could be an issue.
> Some words on the representation of decimal numbers as types. While the
> representation with types of the form D1 (D2 (D3 Sz)) has the advantage of
> allowing numbers of arbitrary size, it has the disadvantage of a growing
> number of parantheses. In my opinion, it would be nicer to have somethink
> like D1 :- D2 :- D9 :- () with a right-associative operator :-. We could
> even build the digit list the other way round—() :- D1 :- D2 :- D9—using a
> left-associative :-. With the latter representation, we wouldn't need to
> reverse digit sequences when adding numbers.
Right, I agree. I think we should use the arbitrary-size
implementation (actually, how arbitrary is it? what's the limit of
GHC, if any?).
To make it friendlier for the end user I thought about defining
aliases for lets say the first 10000 numbers using Template Haskell.
That could even make error reports friendlier (not sure to what point
though). What do you think?
So, we'll be making two separate libraries then. We should think about names.
What about FixedVector for the vector library and DecTypArith (maybe
too long) or DecTypes for the type-level decimal arithmetic library?
I'll put my hands dirty once we agree on this.
Cheers,
Fons
More information about the Haskell-Cafe
mailing list