Let's get this finished

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Wed Jan 10 07:54:15 EST 2001


Simon Marlow <simonmar at microsoft.com> wrote,

> > "Manuel M. T. Chakravarty" wrote:
> > > If hslibs is meant to be used with systems other than ghc,
> > > too - which I think was the idea - there is no choice but to
> > > rewrite it into H98.  But I guess this is essentially up to
> > > Mr. HsLibs aka SimonM.
> > 
> > Well, doing some simple local transformations to get H98 compliance
> > should be possible without consulting Mr. HsLibs in advance.  :-)
> 
> [ blimey.  I go away for a couple of days and you guys are going
> bananas.  Slow down! ]

Too late.  I just checked in the last module.[1]  (And besides,
I thought you wanted to get this done...)

> I should say that I've recently been working on moving most of the FFI
> code into ghc/lib/std, removing GHC's use of deprecated features (eg.
> using Ptr instead of Addr), and converting some of GHC's standard
> libraries to use the new FFI.  Directory has been converted so far.

I don't see a problem moving the new stuff there, too (if
you need it).

> I think there's no alternative to having two copies of much of the code
> - a H98 version in hslibs/lang and GHC-specific code partly in
> ghc/lib/std and partly in hslibs/lang, with appropriate #ifdefs.  We'll
> need to set up a way to test the H98 code using GHC too.

I can understand (dependency-wise) that you want to have
some of the stuff in ghc/lib/std.  However, why don't leave
it in H98.  Having local functions instead of pattern type
annotations doesn't look as nice, but otherwise shouldn't be
a problem.  In some places (like in CError), there are some
#ifdefs to use GHC specific features.

(The story is a bit different for the older system dependent
modules, but they are...aehmm...system dependent, anyway.)

> I don't see any problem with using hsc2hs for the H98 versions, since
> hsc2hs is mostly compiler-independent.  (but I notice you've used
> autoconf instead of hsc2hs for the errno code.  I haven't looked at it
> yet.)

Figuring out how to do loops in aclocal.m4 was easier than
getting the make system to call hsc2hs at the right point
:-)

Besides, IIRC Malcolm said that he isn't to keen on another
tool.

BTW, Malcolm, I think, all the new code should work in NHC
if you want to try.  The main problem is getting the
constants for the error codes as you don't use autoconf for
NHC.  

Cheers,
Manuel

PS: Yes, I'll write sgmls for the new modules, too.

[1] For those who are not on cvs-hslibs, the additional
    marshalling modules that we discussed here recently can
    be inspected in the fptools/hslibs repository.




More information about the FFI mailing list