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