On Fri, 30 Jul 2010, John Meacham wrote:
Heh. I was just thinking I needed type level naturals last night at the pub.
I thought about type level naturals yesterday when working with HList and found that HList's dependency on TemplateHaskell is quite heavy.
I wanted to support gcc's vector type extension in jhc
http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
which allow diretly expressing vector operations that use the SIMD features of modern CPUS, I didn't want to pre-create every possible choice so encoding the size as a type level number makes sense.
The llvm wrapper supports CPU vector data types by decimal type level numbers from the type-level package as phantom type parameters, which I found nice to use. However the whole type level arithmetic is quite slow. Btw. I got to know that there is a difference between Vector computing and SIMD computing, most notably that Vector units (like Altivec and SSE) support vector element shuffling and SIMD machines (like GPUs) do not. http://perilsofparallel.blogspot.com/2008/09/larrabee-vs-nvidia-mimd-vs-simd...