Drastic Prelude changes imminent

Yuras Shumovich shumovichy at gmail.com
Sat Jan 31 19:57:22 UTC 2015


On Sat, 2015-01-31 at 09:59 -0800, Johan Tibell wrote:
> I re-read the goals* of the proposal:
> https://wiki.haskell.org/Foldable_Traversable_In_Prelude
> 
> "One goal here is that people should be able to use methods from these
> modules without the need of a qualified import -- i.e. to prevent clash in
> the namespace, by resolving such in favor of the more generalized versions.
> Additionally, there are some new methods added to the Foldable class
> because it seems to be the "right" thing."
> 
> Before FTP, I would have to write this to use Foldable/Traversable:
> 
>     import qualified Data.Foldable as F
> 
> The import is qualified as to not collide with the Prelude.
> 
> If I have code that needs to be compatible with more than one GHC release
> (I typically need compatibility with the last 3 major releases), what do I
> have to write post-FTP? Since I cannot rely on the Prelude being
> generalized (because I might be compiling with a pre-FTP compiler) I need
> to either write:
> 
>     #if MIN_VERSION_base(x,y,z)
>     -- Get Foldable etc from Prelude
>     #else
>     import Data.Foldable (...)
>     import Prelude hiding (...)  -- the same
>     #endif
> 

You just create custom Prelude.hs and place all the ugly CPP inside it.
Then you continue writing code assuming the generalized prelude for all
`base` versions (or specialized prelude if you prefer.)

I already use custom prelude when I need portability because older base
exports incompatible `catch` from Prelude. That works OK for me so far,
and I don't see why it will not work for FTP.

(I personally hate FTP, but I probably will be able to live with it.)

> Which is terrible. Alternatively I can write
> 
>     import qualified Data.Foldable as F
> 
> but now nothing is gained over the pre-FTP state. Only after 3+ years (at
> the current GHC release phase) I can drop that one extra import. One out of
> perhaps 20. That seems quite a small gain given that we will then have made
> Data.List a very confusing module (it's essentially Data.Foldable under a
> different name), broken some code due to added type ambiguity, and also
> removed one of the simpler ways to remove that ambiguity, which would have
> been to import one of the monomorphic list functions that no longer exist.
> 
> * People tell me that there are other goals, but they aren't really stated
> clearly anywhere.

I'd like to known other goals. Right now it looks for me like saving few
keystrokes.

> 
> -- Johan
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries




More information about the Libraries mailing list