"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! ] 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 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 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.) Cheers, Simon
Simon Marlow <simonmar@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.
participants (2)
-
Manuel M. T. Chakravarty -
Simon Marlow