Core libs summary

[Alastair David Reid]

            ST.
                Lazy            ( portable, provisional )
                Strict          ( portable, provisional )
			***	Don't both variants of ST require runtime
			***	system support?  If so, then not yet portable.
        STRef                   ( portable, experimental )
			***	As with the ST monad, I believe RTS support
			***	or an FFI'd implementation is required?

STRefs and the operations on them are the same in both variants.
The only difference is in the >>= implementation.

So you need runST either as a language extension (as in the Lazy state
thread paper) or using rank 2 polymorphism.  The spec should make it
clear that the (slightly) more restrictive runST implementation is 
cool.

Hmmm, an ffi'd implementation would be possible - but really ugly!


        Bits                    ( portable, experimental )
			***	Not portable.  requires either RTS support
			***	or an FFI'd implementation in C I would think.

But, but, nhc is noted for having all that cool, low-level support -
you really don't have bit ops???

Anyway, an FFI implementation would be useful as a reference implementation.
Need to take care to properly implement the exceptional cases like:

   x `shiftR` 1000 == 0

(C does not guarantee this - you might get a shift of 1000 `mod` 32) 

        Dynamic                 ( portable, experimental )
			***	Doesn't contain a data decl for Dynamic,
			***	but otherwise looks ok.  This doesn't require
			***	any RTS support does it?

Needs 

  unsafeCoerce :: a -> b

GHC's implementation probably hides in their Prelude which is why you
can't see it.

In fact, it's hard _not_ to put it in your Prelude since Exception
depends on Dynamic and Exception likes to be in the Prelude.  (This
was alluded to in my meeting summary last week.)


Which reminds me: does/will nhc support exception handling?

The semantics is tricky but the implementation is just the standard
"trim the stack" kind of stuff with a little tweak for outstanding
updates if you want: GHC does this, Hugs does not.  

The most tedious part is tweaking all the operations that return
errors so that they raise exceptions instead.  Hugs does pattern match
failures and most primops but misses some operations and doesn't do
any of the asynchronous exceptions (they're all _really_ tricky to add
to Hugs).

Also, Hugs doesn't implement the full exception datatype - most
exceptions just return a string containing an error message rather
than DivisionByZero (or whatever).  Most users won't notice the
difference.

        PackedString            ( portable, experimental )
			***	nhc98 implements only the `classic' HBC
			***	interface.  In particular, none of the
			***	ByteArray ops are portable.

I expect this goes for Hugs too.
(I expect (but didn't check) that the Foreign libs need ByteArray ops...)

We could consider an ffi-based implementation which puts PackedStrings
in the C heap but the performance characteristics will be very
different from GHC leading to continual conflicts along the lines of
"but this is cheap"... "only in your implementation"...  

Do nhc PackedStrings live in the Haskell heap?

    NHC.
			***	I'd prefer Nhc or Nhc98.  All caps is horrible.

It's your choice but I'd lean against the 98 - presumably there will
come a time when the 98 isn't appropriate.  (I feel the same way about
the 98 in the directory structure for the Hugs source code.)



-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/