Well I have to say the dataflow style of lazy programming made me think Haskell would be ideal for multi-processor use (and now HyperThreading is common most PCs have more than one processor from the code's point of view)... I was disappointed to find GHC only uses one thread, and therefore will only use one CPU. Vectorisation is much more limited than hyperthreading - as the instructions on each vector unit must be the same... The easiest implementation would be to add primitive vector types that map directly to the underlying SIMD operations. This is probably a good starting point - it would be nice to vectorise normal expressions, but that requires an optimisation search to find instructions that can be grouped together ... this becomes a lot easier if the primitives are supported as you just need to transform the code rather than dealing with non-portable assembly instructions. The problem is that different platforms support different SIMD style instructions... What would be really needed is a IEEE/ISO standard for vector instructions much like the current one for floating point. In the absence of such a standard, the best that can be done is to abstract vectorisation by word size and number of words, and supply a software implementation of all vector ops to use if the hardware does not support certain primitives. A futher point is that for the compiler to know the vector size, you would have to resort to type level naturals... something like: data Nil data Suc x = Suc x type Four = Suc (Suc (Suc (Suc Nil))) myFn :: Vector Four Word16 Of course this would need to be integrated with the compiler. As an interim measure a C-library providing primitive operations on vectors could be written and used via the FFI. Keean.