base-noprelude instead of NoImplicitPrelude

[gregwebs]

This is a path to address the main problem from #109. Although I am not sure if as it currently stands it will create a problem from exporting a Prelude module.

base-noprelude serves the same end but avoids using a language extension

If we like this direction,
The setup should be altered so that Prelude.hs is Import.NoFoundation

[snoyberg]

I have no experience with base-prelude, but it sounds like an interesting solution to the problem. That said, I think we may end up with more confusion from users who see no special preludes imported and yet non-default-Prelude behavior present. That said, it's not like the current situation doesn't lead to that confusion either...

So how's this: if it works with Stack, I'm on board with the change.

[gregwebs]

To be more explicit we probably could use base-noprelude and still explicitly import an Import module. We may still need to define a Prelude module but it would just be empty (with a comment pointing to Import).

[snoyberg]

That's a very interesting idea.

On Mon, Nov 23, 2015 at 7:14 AM, Greg Weber notifications@github.com
wrote:

To be more explicit we probably could use base-noprelude and still
explicitly import an Import module. We may still need to define a Prelude
module but it would just be empty (with a comment pointing to Import).

—
Reply to this email directly or view it on GitHub
#111 (comment)
.

[gregwebs]

Unfortunately stack ghci does not seem to like this solution. I don't know how to deal with this problem because the ghci fails to load, which seems like a stack bug.

➜  yesod-scaffold git:(base-noprelude) ✗ stack ghci
Using main module: Package `PROJECTNAME' component exe:PROJECTNAME with main-is file: /home/greg/hs/y/yesod-scaffold/app/main.hs
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: PROJECTNAME
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help

<interactive>:1:1:
    attempting to use module ‘Prelude’ (/home/greg/hs/y/yesod-scaffold/Prelude.hs) which is not loaded

[meteficha]

IMHO, I think that the language extension is more widely recognized than base-noprelude, thus it would be better to keep using it.

[gregwebs]

@meteficha we would prefer that also but are trying to balance making stack ghci work well.

[snoyberg]

There is the option of just putting NoImplicitPrelude in each module.

[gregwebs]

I am ok with a standard boilerplate line for some language extensions. They seem pretty unavoidable for the others anyways. @meteficha what do you think?

{-# Language NoImplicitPrelude, OverloadedStrings, NoMonomorphismRestriction #-}

[meteficha]

Hmmm, I didn't know there was an issue with NoImplicitPrelude being on .cabal. I don't like LANGUAGE pragmas being on every file, so it's a tough decision :).

[gregwebs]

I tried out base-noprelude on a different non-yesod project and got the same result from stack ghci.

 attempting to use module ‘Prelude’ (... Prelude.hs) which is not loaded

So I am stumped on base-noprelude right now and favor putting the bothersome language extensions in each file.

[snoyberg]

@gregwebs Just noticing we left this open. You OK with closing this and following up on #109?