Provide a complete prelude, rename BasicPrelude? about basic-prelude HOT 6 CLOSED

+1 for CorePrelude.

from basic-prelude.

OK, I've moved BasicPrelude.hs to CorePrelude.hs, and thrown together a quick BasicPrelude that defaults to using Text and FilePath instead of String under the common use cases, and otherwise exports everything that Prelude does (assuming I haven't missed anything), meaning that it has the same List bias for pretty much everything that isn't obviously Text. I wasn't quite sure what to do with interact and getContents, so I arbitrarily decided to use [Char] for the former and LText for the latter.

The import list from Prelude can help guide us to determine which things should be migrated to CorePrelude. After I think about it for a little while I'll open an issue suggesting a few migrations, and once we get those settled we can start thinking about releasing version 0.2.

from basic-prelude.

Instead of grabbing sequence, mapM, and a few others from Prelude, why not re-export all of Control.Monad?

from basic-prelude.

Everything in Control.Monad looks like a good fit to me. I could see an argument for not including functions like liftM and ap, since we should be using <$> and <*> instead, but until we fix the typeclasses themselves, there are times when the monadic versions are necessary.

from basic-prelude.

The question is, how much of it should be in BasicPrelude vs CorePrelude? Of course Basic Prelude can just re-export all of Control.Monad regardless of what CorePrelude exports from it. CorePrelude will have to be more selective, rejecting (for instance) anything with lists in the type signature.

from basic-prelude.

I've added Control.Monad to BasicPrelude's exports, and added a test file that trivially uses all of the things that Prelude exports, as a sort of ad-hoc test for a given module's suitability as a complete Prelude replacement.

from basic-prelude.