[Haskell-cafe] Re: CComplex in jhc (was: Word128, Word256)

[John Meacham]

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/