RE: unsafePerformIO and unsafeInterleaveIO
Without a standard way to get at unsafePerformIO, such code would still rely on non-standard features, which goers against the aim of standardising the rest of the FFI.
The Hugs-GHC standard libs have them exported from IOExts.
Of course, the Hugs-GHC standard isn't an official Haskell library committee approved standard but, since it's something like 4 years old, I think it's a better candidate for approval than the ffi library which hasn't really stabilised yet, hasn't been whacked on by a large number of users, is much younger, etc.
Sadly, due to lack of support on the Hugs side, the Hugs/GHC extension libraries have drifted apart. I would have liked Hugs to ship with a cut-down hslibs at some point (and indeed there's some support in the hslibs build system for Hugs), but there was no-one available at the Hugs end to do the work and make it happen. Longer term, the effort currently underway on libraries@haskell.org should eventually provide a unified story for "extension" libraries. Cheers, Simon
Sadly, due to lack of support on the Hugs side, the Hugs/GHC extension libraries have drifted apart.
Sadly true. But any parts of the standard that haven't changed in the last 2.5 years (e.g., unsafe{Perform,Interleave}IO) still work - so in this case it can be relied upon. Alastair ps I wonder if it'd be possible to merge them by doing this in the hslibs repository: 1) Move the STG Hugs ifdefs out of the way: find . -name '*.[l]hs' | xargs perl -p -i -e's/__HUGS__/__STG_HUGS__/' The __HUGS__ label made sense when I expected CLassic Hugs to be replaced by STG-Hugs - but it wasn't so it should be renamed. 2) Merge in the current Classic Hugs libs (using ifdef __HUGS__). (There's a question of what to do with the Hugs libs which don't exist in the Hugs-GHC standard. I imagine that GHC merrily puts GHC-specific files into the repository and that'd be the thing to do with Hugs files. In each case, a giant ifdef round the whole file would prevent it from troubling the other party.) 3) Add enough infrastructure to make it easy to checkout a working version of Hugs based on the hslibs repository. This would require a choice of running with -Fhscpp or using a makefile (or whatever) to convert all the files over so that you can run without hscpp and so that you can build Hugs distributions. (Also requires moving files around to match Hugs' current directory tree - no big deal.) (It'd also mean that code freezes during the runup to a Hugs release would extend into some of the hslibs, an expectation that other hslibs hackers would make at least a minimal effort to test that their changes don't accidentally break Hugs (which requires a simple Hugs test harness for them to run now and then), etc.) I think it'd be important to do this in an incremental way: setup some infrastructure now, merge a few libraries now, leave the others to be done later as time and needs dictate. pps Should this happeen, I have a bunch of changes to the Hugs version of the Pretty library that I'd like to commit - all to do with strictness annotations required with unboxed types. (Or maybe Hugs should have "strict ints" added to it - call that type Int# and they'd behave like Int from the strictness point of view.)
participants (2)
-
Alastair Reid -
Simon Marlow