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