On Mon, Oct 26, 2009 at 12:24:39AM -0200, Maurício CA wrote:
Well, before trying to get it standardized, you need to get it implemented and tested by at least one compiler to explore the design space and tradeoffs. I would happily accept any patches into jhc that a support for such types, I don't even think it would be that difficult to do.
One should say jhc code is really clear. It's the first compiler code I try to read and for a moment I actually believed I could write the patch :)
excellent :)
Below is my completely naive attempt. If you want to tell me where to go from here, I'll try. (For instance: how do I get 'rt_bits_double_complex_' to exist.) However, I think this is far beyond my skills...
A fairly good first attempt. The main issue is that 'primitives.txt' and its associated machinery is the old way of defining primitives that is slowly being phased out. Basically, what primitives.txt did was centralize a lot of 'compiler magic' as in, it created a lot of instances for things like Num and Storable that one might expect for built in types. However, as jhc progressed, it became clear that having things built into the compiler is a real pain. Hence, for newer primitives, they are simply implemented in pure haskell. as in, instead of some magic 'data Int' somewhere and a lot of compiler defined primitives, we have 'data Int = Int Word32_' and plain instance declarations like 'instance Num Int where ...' and so forth, with primitive operators being foreign imported. So, Double and Float have both been fully converted to the new way of doing things, so look at their implementation to see how complex versions of them should be handled. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/