<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] That being said, as how to write your Monad instances today with GHC<br>
7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This<br>
*does* work (admittedly for an easy example, but this can be<br>
generalised):<br>
<br>
<br>
--8<---------------cut here---------------start------------->8---<br>
module MyMaybe where<br>
<br>
import Control.Applicative (Applicative(..))<br>
import Prelude (Functor(..), Monad(..), (.))<br>
-- or alternatively: `import qualified Prelude as P`<br>
[...]<br>--8<---------------cut here---------------end--------------->8---<br>
<br>
This example above compiles -Wall-clean and satisfies all your 3 stated<br>
requirements afaics. I do admit this probably not what you had in mind.<br></blockquote><div><br></div><div>OK, so the trick is that you're effectively hiding Applicative from the Prelude (which might be a no-op). This "works" somehow, but is not satisfactory IMHO for several reasons:</div><div><br></div><div>   * If you explicitly import all entities from Prelude, your import list will typically get *very* long and unreadable. Furthermore, if that's the suggested technique, what's the point of having a Prelude at all?</div><div><br></div><div>   * Some people see qualified imports as the holy grail, but having to prefix tons of things with "P." is IMHO very ugly. Things are even worse for operators: The whole notion of operators in itself is totally useless and superfluous *except* for a single reason: Readability. And exactly that gets destroyed when you have to qualify them, so I would (sadly) prefer some #ifdef hell, if that gives me readable code elsewhere.</div><div><br></div><div>   * With the current trend of moving things to the Prelude, I can envision a not-so-distant future where the whole Control.Applicative module will be deprecated. As it is now, it's mostly superfluous and/or contains only stuff which might better live somewhere else.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] That's because -Wall-hygiene (w/o opting out of harmless) warnings<br>
across multiple GHC versions is not considered a show-stopper.<br></blockquote><div><br></div><div>That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] Beyond what Ben already suggested in another post, there was also the<br>
more general suggestion to implicitly suppress warnings when you<br>
explicitly name an import. E.g.<br>
<br>
  import Control.Applicative (Applicative(..))<br>
<br>
would suppress the redundant-import warning for Applicative via Prelude,<br>
because we specifically requested Applicative, so we don't mind that<br>
Prelude re-exports the same symbol. [...]<br></blockquote><div><br></div><div>Uh, oh... That would be bad, because one normally wants to see redundant imports. Without the compiler telling me, how should I find out which are redundant? Manually trying to remove them step by step? :-/</div><div><br></div><div>Cheers,</div><div>   S.</div></div></div></div>