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