[Haskell-cafe] Re: Hidden module?

[John Meacham]

On Sun, Mar 01, 2009 at 11:03:41PM +0000, Duncan Coutts wrote:
> > They serve different purposes, hsc2hs is meant to run on the actual
> > machine the library is being _built_ _for_ to obtain information that is
> > only available on the final build architecture/operating system. as in,
> > an hsc file is the lowest level portable code you can write. c2hs is
> > more of a developers tool. If anything, I think c2hs should generate hsc
> > files, which can then be portably distributed.
> 
> Like hsc2hs, c2hs has to be run using the C headers for the target
> machine. It needs these to calculate struct sizes like hsc2hs does. The
> reason it cannot generate .hsc files and leave the rest to hsc2hs is
> that it also generates Haskell ffi imports. It imports the C functions
> at the correct Haskell types. If the C headers on a different platform
> are quite different then we will get a type error at compile time. With
> hsc2hs we'll just get a segfault. So c2hs and hsc2hs are in the same
> class here. They both must be run for the target machine.

It still seems like you can get almost all the way there by generating
things like (#type guint) in the hsc file. You would not be able to work
around APIs that actually differ between architectures, but those are
not all that common beyond the inherent incompatabilities due to C
calling conventions and structure layouts. As in, you should be able to
produce portable hsc files for everything that we could have written
portable C code for in the first place, which is a large percentage of
libraries.

The other reason it would be nice is then we have a clear seperation of
concerns, c2hs would just need generic header files, while hsc2hs
requires an actual target build environment. Allowing people to build
projects that used c2hs with just hsc2hs and not having to install c2hs
in the majority of cases.

The other reason is that it means that cross compiler support only needs
to be implemented in one place, whatever interprets the hsc file. For
instance, jhc is a cross compiler by nature, a mac OSX binary created on
a linux box is equivalent to one you would create sitting at the mac OSX
box and compiling it natively. Generally, bringing this about is quite
straightforward,

; jhc --progc i386-mingw32-gcc -mgeneric HelloWorld.hs -o HelloWorld.exe
; wine HelloWorld.exe
Hello, World!

but when you involve hsc files things get a bit trickier, since it
requires not just having access to the appropriate compiler, but the
ability to run the resulting program. I'd like to remove that
requirement, my current plan was to have jhc natively and transparently
handle hsc files just like hs files. a (#type guint) will propagate
through all the passes and actually become a 'guint' in the generated C
file, likewise, for (#const ..) and other hsc declarations. As in, I am
treating hsc files as a sort of standard way to express cross platform C
compatability that all compilers should support (either natively or via
hsc2hs) rather than specific input to hsc2hs. 

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈