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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe