Changes between Version 10 and Version 11 of NoImplicitPreludeImport


Ignore:
Timestamp:
May 28, 2013 3:03:16 PM (2 years ago)
Author:
igloo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NoImplicitPreludeImport

    v10 v11  
    6565It may also be beneficial to EDSL designers, who wish to reuse `Prelude`
    6666names for different functions.
     67
     68It is possible that this would lead to a large number of alternative
     69Preludes, all slightly different.
     70On the other hand, perhaps this has already happened
     71([http://hackage.haskell.org/package/basic-prelude 1]
     72[http://hackage.haskell.org/package/ClassyPrelude 2]
     73[http://hackage.haskell.org/package/classy-prelude 3]
     74[http://hackage.haskell.org/package/custom-prelude 4]
     75[http://hackage.haskell.org/package/fugue 5]
     76[http://hackage.haskell.org/package/general-prelude 6]
     77[http://hackage.haskell.org/package/gofer-prelude 7]
     78[http://hackage.haskell.org/package/interlude 8]
     79[http://hackage.haskell.org/package/modular-prelude 9]
     80[http://hackage.haskell.org/package/modular-prelude-classy 10]
     81[http://hackage.haskell.org/package/numeric-prelude 11]
     82[http://hackage.haskell.org/package/prelude-extras 12]
     83[http://hackage.haskell.org/package/prelude-generalize 13]
     84[http://hackage.haskell.org/package/prelude-plus 14]
     85[http://hackage.haskell.org/package/prelude-prime 15]
     86[http://hackage.haskell.org/package/simpleprelude 16]
     87[http://hackage.haskell.org/package/yap 17]), in which case lowering the barrier
     88to using alternative Preludes may help determine a winner. However, it seems more
     89likely that the vast majority of developers will continue to import modules from
     90`base` instead, rather than add a dependency on another library.
    6791
    6892== Related issues ==