Export lists in modules
ketil+haskell at ii.uib.no
Thu Feb 23 07:32:44 EST 2006
Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:
> you would simply replace the implicit "import Prelude" with
> an explicit "import Prelude.Standard" (or use a build flag like
> -fimplicit-prelude, or +98).
Why not keep it implicit? If you want the alternative behavior, you
know where to get it (import Prelude (), -fno-implicit-prelude, etc).
This way, you avoid breaking a lot of existing code, and also a lot of
"hello world"-class programs could be written without any explicit
imports or special tricks.
Any programs written to use a more granular set of Prelude modules,
would likely need an array of imports anyway, so the loss would be
less in that case.
> Some data-structures people (e.g. Chris Okasaki) are of the opinion that
> lists tend to be over-used (because they are built-in), when other
> datatypes might be much more appropriate.
Hmm...so the best way to educate programmers about this is to make
lists harder to use? :-)
Anyway, I'll see your Okasaki, and raise you one Simon Thomson (since
"The Craft.." is the only Haskell book I have on my desk at the moment).
Lists aren't mentioned until chapter 4, but chapter 4 and 5 discuss
lists, chapter 5 is called "Generalization", but as far as I can tell,
still talks exclusively about lists, and in the remaining chapters,
there are lists on nearly every page.
Over-used, perhaps, but the fact is that lists are - like it or not -
a staple of FP in general, and Haskell in particular.
Now, I'm sure a lot of uses for List could be replaced by more
specific and appropriate types: Stack, LazyStream, IterationMonad,
Deque, FingerTree etc etc. But this adds complexity to your program
- if a list does the job well enough, why not use it? I'm reminded of
one of the XP idioms: always first try to solve the problem in the
simplest way that can possibly work.
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-prime