John Meacham: > On Tue, May 02, 2006 at 03:29:16AM +0000, Aaron Denney wrote: > > On 2006-04-29, Manuel M T Chakravarty <[EMAIL PROTECTED]> 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)
I agree that this would be cool, but I think it goes beyond Haskell'. It is not just a matter of data types. For it to be useful, you need to generate the right code, too. Manuel _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
