...

...

As a point of interest, is there a good reason why the Exception type needs to be in the Prelude?

...

because you want to define error by something like: error msg = Exception.raise (Exception.Error msg)

I'm still not entirely sure I understand why a qualified import into the Prelude implementation (as you have illustrated here) is not sufficient. Does Exception need to be hardwired into the Prelude? For a comparable example, think of type Prelude.Rational which is defined as (Ratio.Ratio Prelude.Integer). The Ratio type is not in the prelude, just used by it.

I think you two are using different notions of what "in the Prelude" means. Alastair seems to be taking it to mean "everything below Prelude in the dependency tree", and Malcolm is using "everything defined originally by the Prelude module" (I think (?)). In the core libraries, there is a great deal of stuff below the Prelude in the dependency tree. I didn't worry too much about this, because I want the Prelude to be "just another module", which the user can replace if necessary. The down side is that Hugs' startup times will be longer if it has to chase several modules in order to satisfy the Prelude's imports. But I suggest we actually see whether this is a problem or not before restricting our design. (aside: I really think we should have an alternative, reduced, Prelude that doens't export any I/O stuff for example). Cheers, Simon