On Tue, May 02, 2006 at 03:29:16AM +0000, Aaron Denney wrote:

On 2006-04-29, Manuel M T Chakravarty wrote:

...

Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:

...

On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:

...

I was curious if ghc could support the following basic types, they will likely just be aliases of existing types.

WordPtr uintptr_t WordMax uintmax_t IntPtr intptr_t IntMax intmax_t

all these C types are defined by ISO C so should be available, otherwise, they are easy enough to generate in ghcs autoconf script.

jhc provides these under these names in Data.Word and Data.Int. they would be useful for writing jhc/ghc portable low level code, and writing 32/64 bit safe code.

oh, I forgot the all important conversion routines,

ptrToWordPtr :: Ptr a -> WordPtr wordPtrToPtr :: WordPtr -> Ptr a

ptrToIntPtr :: Ptr a -> IntPtr intPtrToPtr :: IntPtr -> Ptr a

jhc makes these available in Jhc.Addr, but if ghc decides to provide them in a common spot (Foreign.Ptr maybe?)

then I will have jhc follow suit.

I'd also propose these be added to the FFI standard.

I collect additions to the FFI on the Haskell' wiki:

http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface

I added a note about these types. Any other ISO C types that we should include?

complex <foo>.

not ISO C, but I think they would be very cool to provide http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Vector-Extensions.html various vector (SSE, MMX, SIMD) types that are machine independent and compiled to whatever vector processing instructions the underlying arch supports. (pretty much all support some sort of them nowadays) also, incidentally, for anyone on x86 that cares about math performance, use -optc-fsse2 to make it use the much nicer math coprocessor available on modern x86 cpus. (this is the default on x86-64) John -- John Meacham - ⑆repetae.net⑆john⑈