Export lists in modules

[Ketil Malde]

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:

> One of the problems with the current mechanism for overriding Prelude
> definitions, is that every module that /uses/ such an entity must
> also explicitly hide the original Prelude:

I guess I don't quite understand what you are trying to achieve.

Case one: existing project where you want to replace the Prelude

  Subcase a: the project already has a dummy module MyPrelude which just
             reexports the Prelude, and which is imported everywhere.  
             - Great, all you need to do is modify MyPrelude!
             - Benefit from your proposal: you could skip import
               Prelude () from all .hs files (or -fno-implicit-prelude
               from your Makefile)
             - Drawback: anybody actually *do* this in real code
               without concrete plans for Prelude replacement?

  Subcase b: you don't have a MyPrelude.
             - Too bad, you need to modify all your .hs files *anyway*
             (Unless the good and benevolent secret keepers of the
             compiler code would implement a -fprelude-is MyPrelude 
             switch)

  Subcase c: you want an alternative Prelude only in some of your
             files.  Well, you are going to need to modify those files.
             At least you get to leave the rest alone.           

Case two: a new project with a different Prelude

    Well, if you're starting a new project, you can of course 
    choose your own imports as you wish.  Currently, the cost
    in one extra line in each file or the -fno-implicit option. 
            
I don't think saving one line from each file in projects using
alternative Preludes justify adding one line to each file in projects
using the standard Prelude.  If there is any reason to think custom
Preludes will outnumber the standard one, I'll change my mind.

This sounds like yet another feature that is greatly interesting and
wonderful to language hackers, and mostly annoying to the average
programmer - partly by requiring extra overhead and boilerplate stuff,
and partly by breaking old code.

To summarize:

* I don't think this is a good solution to name clashes; to use
e.g. Set (and, hey, I agree with Okasaki and you that it should
probably be used more instead of lists) I would need to use
fine-grained imports management which adds administrative overhead.

(A simple rename of a couple of offending identifiers would solve the
problem. Why not 'isEmpty' instead of 'null', for instance?)

* The standard Prelude is IMO going to be vastly more common than
custom replacements.  Custom Prelude users are also likely to be more
accomplished Haskell programmers.  Any administrative burden should be
on the custom Prelude users.

* That said, I'm all in favor of a switch to tell the compiler to use
a custom module instead of the implicit Prelude.  Or perhaps more
generally: provide an implicit, project-wide import?  Something like:

   ghc --make -fno-implicit-prelude -fimplicit-import MyPrelude Main.hs 

* Much of my resistance would go away if I had better tools to manage
module interfaces more automatically.  As it is now, import/export
administration is already enough of a chore to be noticeable.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants