Core libs summary

[Malcolm Wallace]

			Control.Monad.ST.*
			------------------
Simon:
> Sorry, I thought NHC had the ST monad.  Ok, I'll mark it non-portable
> for the time being.  Actually to implement it all you need is a bit of
> typechecker support for runST and that's it, though.

I love it when people say "you just need to hack the type system a
little bit".  :-)  Nhc98's implementation of type inference could do
with some knowledgable volunteers to (a) help it cope with higher
kinds, (b) add runST, (c) add MPTC, and (d) other cool things.
In fact, a complete rewrite would probably be the ideal strategy,
since no-one really understands how it works now, neither its original
author nor our resident type hacker!

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

Which of the two implementations is the more restrictive?

			Data.Bits
			---------
Simon:
> I was thinking that Bits is required by Data.Word & Data.Int, which are
> in turn required by the Foreign stuff, but you can perhaps get away
> without exporting Bits instances from these modules.

Don't get me wrong, I think we need a Bit/Bits library.

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

nhc98 does indeed have bit-ops, but to the proposed Haskell 1.3 design,
not whatever ghc ended up with.  Anyway, my point was really only that
the code for this library gives an very non-portable implementation,
when a pure FFI one would be preferable.

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

Or indeed, you might get a left shift, or a random bit pattern.
Isn't the K&R phrase "the behaviour is undefined" just great?

> Perhaps we could make 'instance Bits Integer' optional, because that's
> probably the hardest bit.

Blink.  What exactly would such an instance mean?

			Data.Dynamic
			------------
Alastair:
> Needs 
>   unsafeCoerce :: a -> b

Simon:
> It requires unsafePerformIO & IORefs, but that's all.

Ok, nhc98 has all those, so no problem.

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

Ah, but we don't have Exceptions.  As a point of interest, is there
a good reason why the Exception type needs to be in the Prelude?

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

No, but would love to.

			Data.PackedString
			-----------------
Alastair:
> (I expect (but didn't check) that the Foreign libs need ByteArray ops...)

No, I believe ByteArrays have been made obsolete by
Foreign.Marshall.Array which provides packed arrays of any type,
not just bytes.

> Do nhc PackedStrings live in the Haskell heap?

Yes.

			NHC vs Nhc
			----------
Alastair:
> It's your choice but I'd lean against the 98 - presumably there will
> come a time when the 98 isn't appropriate.

Granted.

Simon:
> Ok, Nhc it is.  But it looks horrible next to GHC :-)

So you know what my answer is already...  :-)

			System.*
			--------
Simon:
> I think it would be great if we
> could all use the same implementations of these libs, though.

Absolutely agreed.

> The implementations of CPUTime, Cmd, Environment, Exit, Time, and
> Directory are all rewrites of the original GHC versions to use the new
> FFI & Foreign libraries, so they should be quite portable.  You do need
> hsc2hs and a suitable config.h, though.

Some examples of small GHC-isms:

    module System.Cmd
    system "" = ioException (IOError Nothing InvalidArgument
				 "system" "null command" Nothing)

The `ioException' function and `IOError' constructor are not portable.

    module System.Environment
    foreign label "prog_argv" prog_argv_label :: Ptr (Ptr (Ptr CChar))
    foreign label "prog_argc" prog_argc_label :: Ptr CInt

The "prog_argv" and "prog_argc" labels are not exactly standard.

None of these is a huge problem of course - when we get down to
compiling and running the code, it should be pretty straightforward
to rectify these little things.

Regards,
    Malcolm