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

[Alfonso Acosta]

Don't expect anything astonishing yet, but an initial version of the
library can be found at

http:/code.haskell.org/type-level

To make reviewing easier I have put the haddock-generated documentation at

http://code.haskell.org/~fons/type-level/doc/

Some remarks:

* Only Positive and Natural numerals in decimal representation are
supported. It would be cool to add support for Integers though.

* The code is based on Oleg's implimentation of type-level binaries
http://okmij.org/ftp/Computation/resource-aware-prog/BinaryNumber.hs

* exponentiation/log and GCD is not implemented yet

* multiplication is not relational and thus division is broken. I
tried porting Oleg's multiplication algorithm without success.

* Aliases (in binary, octal decimal and hexadecimal form) for
type-level values and their value-level reflection functions are
generated with TH.
  That implies:
    * Long compilation time depending on your system
    * Although errors will always be reported in decimal form, the end
user can input values using other bases (only for values in the range
of generated aliases of course)

* It would be cool to have "real" support for other bases apart from decimals
  * It would imply having unlimited size of input for other bases
(right now if we want to input a value out of the alises limit,
decimal reprentation is mandatory)
  * However, is it feasible? How could it be done without needing to
implement the operations for each base? WOuld it be possible to
"overload" the type-level operators so that they worked with different
representations and mixed representation arguments?

* Booleans are not implemented (Wolfgang?)

I would be happy to hear any suggestions, get code reviews and/or contributions.

Cheers,

Fons








On Feb 7, 2008 11:17 AM, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> Am Donnerstag, 7. Februar 2008 02:47 schrieb Alfonso Acosta:
> > > The other library I use for type-level programming is HList. It has
> > > type-level booleans already so you might what to take a look at it if
> > > you're not already familiar with it.
> >
> > Thanks I'll have a look at it.
>
> I have to admit that I don't like the names HBool, HTrue and HFalse.  What do
> they mean?  Heterogenous booleans?  Heterogenous truth?  Why it's "Bool"
> instead of "Boolean" and therefore not conforming to the Prelude convention?
>
> Heterogenous lists are not directly about type level computation.  A HList
> type is usually inhabited.  On the other hand, types which denote type level
> naturals or type-level booleans are empty data types.  So type level booleans
> should go into some type level programming library like the one Alfonso and I
> want to create.  HList should then use these booleans.  This is at least my
> opinion.
>
> Best wishes,
> Wolfgang
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>