HI, Am Donnerstag, den 23.05.2013, 12:38 +0400 schrieb Anton Kholomiov:

I wish it was possible to use an extension

CustomPrelude = Prelude.Prime

In the cabal file

as far as I know, GHC simply issues an implicit import Prelude without package qualifiers. So you can get what you want by not depending on base, but rather have prelude-prime re-export all modules from base plus its own Preldue. A more modular variant would be to have a package "preludeless-base" which re-exports all modules from base but the prelude. Then you can select which prelude you want simply by depending on preludeless-base (instead of base) plus a package (say prelude-prime) which exports a module named Prelude. If prelude-prime itself wants to use base, it can still use package-qualified imports. Or it could itself be based on preludeless-base. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Hi, Am Donnerstag, den 23.05.2013, 11:52 +0200 schrieb Bas van Dijk:

On 23 May 2013 11:26, Joachim Breitner wrote:

...

So you can get what you want by not depending on base, but rather have prelude-prime re-export all modules from base plus its own Preldue.

How would you re-export all base's modules from the prelude-prime package? I didn't know this was already possible.

manually... you create a .hs file for every module in base, which imports the module in base (using a package-qualified import), gives it a qualified name and puts that name in the export list. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On Thu, May 23, 2013 at 11:38 AM, Anton Kholomiov

wrote:

I wish it was possible to use an extension

CustomPrelude = Prelude.Prime

In the cabal file

I'm not necessarily opposed to this idea, but I'd like to point out that it can have a negative impact on readability of an individual module, since you can't tell which Prelude is being used. This is the same argument used for putting LANGUAGE pragmas in a modules instead of listing them in a cabal file. I think in the case of an alternate Prelude, the argument is stronger, since language extensions often don't change the meaning of code, but instead allow previously invalid code to be valid. Michael

* Manuel Gómez [2013-05-23 08:33:15-0430]

On Thu, May 23, 2013 at 3:07 AM, Roman Cheplyaka wrote:

...

Pull requests are welcome, but let's stick to widely agreed changes (like the Foldable/Traversable one). I think one of the reasons why other Preludes haven't been adopted is because they were too radical.

* Andreas Abel [2013-05-20 13:26:05+0200]

...

Maybe instead of fiddling with the current Prelude (which might break backwards compatibility), we should design a new prelude which is not automatically loaded but contains roughly the current prelude (with the list functions generalized to collections) plus the "modern" type class stack: Functor, Applicative, Monad, Foldable, Traversable, Monoid etc.

Is this strategy adequate for attacking the issue of the type class stack, though? Defining, say, a new Monad class with the desired Functor constraint wouldn’t be of much use, as everything else on Hackage (and on the GHC libraries!) would still use the “real” Monad.

No, it definitely isn't. Roman