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

Dan Weston westondan at imageworks.com
Thu Feb 7 14:38:48 EST 2008

```I know that naming is arbitrary, but...

Digits in types seems ugly to me. In this case, it is also redundant.
Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem
clear. Nat0 could even mean Nat \ {0}, the opposite of what is proposed,
so confusion is even increased with Nat0.

Dan

Alfonso Acosta wrote:
> On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
>> Nat means "all natural numbers except zero" while Nat0 means "all natural
>> numbers (including zero)".  Since in computer science, natural numbers
>> usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0.
>
> Sounds sensible, actually Nat and Nat0 is confusing. However I would
> rather use Pos and Nat0 to make explicit that naturals include zero .
>
> Depending on the definition of naturals they might or might not
> include zero.  http://en.wikipedia.org/wiki/Natural_number
>
>> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2.  But I think, the
>> latter representation should probably be prefered.  With it, :+ always has a
>> number as its left argument and a digit as its right.  Without the () :+ we
>> get ugly exceptional cases.
>> You can see this, for example, in the instance
>> declarations for Compare.  With the second representation, we could reduce
>> the number of instances dramatically.  We would define a comparison of digits
>> (verbose) and than a comparison of numbers based on the digit comparison (not
>> verbose).
>
> Even if () would be preferred from the programmers point of view (I'm
> not sure how much we could reduce the number of instances though), it
> makes the representation less attractive on the user-side. Anyone
> using the library would find it annoying and would wonder why is it
> neccessary.
>
> Unless we find a way to use () only internally (we should use a
> one-character type to make it shorter to type) I think we should stick
> to current representation.
>
>> :+ is already used as the constructor for complex numbers.  We should probably
>> use some different operator.
>
> Right. I didn't think about that, thanks.
> _______________________________________________