Hello Ashley, Monday, December 26, 2005, 2:41:38 PM, you wrote: >> On the whole it looks like you want type variables with kind #. >> There are very good implementation reasons for not allowing this. >> If you had type variables of kind # you could have polymorphic >> functions over unboxed values. But since the values are unboxed >> they don't have a uniform representation (e.g., a Double# is probably >> twice the size of a Float#). So polymorphic functions over unboxed >> values are not easy to implement. (You can imagine implementations >> of them, but none of them are pleasent.)
AY> Oh, I hadn't thought of that. AY> One solution might be to have a kind for each kind of storage: AY> * for boxed values AY> #4 for 4-byte values AY> #8 for 8-byte values AY> #P for pointers to things that need to be GC'd (or whatever) AY> etc. AY> Do you think this would work? it's unserious :) overloading of unboxed types must be resolved at compile time, as in C++ templates. Haskell polymorhism, based on using of type classes, oriented to run-time resolving of polymorphic usage, although SPECIALIZE/INLINE/RULES pragmas can optimize code, the program must remain correct without these pragmas and therefore overloading is limited to boxed types. aside of different sizes, boxed values carry dictionaries used to run-time resolving of overloaded functions. where unboxed value must hide this dictionary? :) but i'm totally agree that we must have C++-like compile-time overloading in order to create fast programs -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
