unsafePerformIO and unsafeInterleaveIO

Alastair Reid reid at cs.utah.edu
Wed Mar 21 13:56:11 EST 2001

> 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.


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.)

More information about the FFI mailing list