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

Robin Palotai palotai.robin at gmail.com
Wed Jul 16 15:18:25 UTC 2014


I worked a bit (not too much to this point) with adding toolage, and I have
to say I agree with those above who say that things should be explicit if
possible, since every special case makes the entry barrier of new tools a
little bit higher. The more uniform we can go with features the better.


2014-07-16 16:51 GMT+02:00 Carl Howells <chowells79 at gmail.com>:

> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140716/1cd3b7f4/attachment.html>


More information about the Haskell-Cafe mailing list