[Haskell-cafe] Feature Proposal: GHC Flag for implicit external Prelude

[Carl Howells]

If you want a prelude tailored to a specific project, you don't need
this extension at all.  Just create a module named Prelude in your
project.

Actually, given that, I'm not sure what the actual value of this flag
would be. What does it add over just putting a Prelude module in your
project? I guess it would work better for the case when you want a
pre-packaged Prelude replacement, instead of a custom one.  But in
that case, be very sure this flag supports loading the Prelude module
from an installed package, instead of from source.

On Wed, Jul 16, 2014 at 3:46 AM, L Corbijn <aspergesoepje at gmail.com> wrote:
> Another problem with making it (cabal) global is that you have to
> separate the alternative Prelude (and the modules it depends on) from
> the rest of the modules. Otherwise you would have an circular
> dependency by importing the new Prelude in the new Prelude you are
> defining.
>
> For project specific preludes I can think of two options. Separate
> into a package/library, which will probably be more trouble than it
> would solve in the first place. Alternatively there could be a
> mechanism for excluding the automatic new Prelude import, which would
> make things only more complicated. Either way it seems that it would
> make things only more difficult if you want a prelude tailored to a
> specific project.
>
> Lars
>
> On Tue, Jul 15, 2014 at 7:30 PM, Michael Orlitzky <michael at orlitzky.com> wrote:
>> On 07/14/2014 11:23 PM, Andrew Gibiansky wrote:
>>> Hey all,
>>>
>>> I would like to propose a very minor flag to add to GHC. I would like
>>> GHC to have a --with-prelude flag, which would specify an alternate
>>> Prelude to use instead of the default Haskell prelude.
>>>
>>> This would have an effect similar to -XNoImplicitPrelude and an additional
>>>
>>> import MyNewPrelude
>>>
>>> in the source file. It might be a /little/ different semantically, as a
>>> qualified import would disable the original implicit import, just like
>>> it does with the default Haskell prelude.
>>>
>>
>> To play devil's advocate, I don't think this is a good idea. It moves
>> information that is fundamentally local (which library imports a module
>> requires) into global state: magic flags that must be passed to the
>> build system for anything to work.
>>
>> It would be super annoying for an {IDE, coworker, ...} to have to
>> analyze your build system just to figure out which functions are in scope.
>>
>> We went down this road once before with -fglasgow-exts. Eventually, we
>> all realized it was much better to place the required extensions in
>> pragmas at the top of the file.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe