[Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

[Sven Panne]

2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:

> [...] That being said, as how to write your Monad instances today with GHC
> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
> *does* work (admittedly for an easy example, but this can be
> generalised):
>
>
> --8<---------------cut here---------------start------------->8---
> module MyMaybe where
>
> import Control.Applicative (Applicative(..))
> import Prelude (Functor(..), Monad(..), (.))
> -- or alternatively: `import qualified Prelude as P`
> [...]
> --8<---------------cut here---------------end--------------->8---
>
> This example above compiles -Wall-clean and satisfies all your 3 stated
> requirements afaics. I do admit this probably not what you had in mind.
>

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:

   * 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?

   * 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.

   * 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.


> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
> across multiple GHC versions is not considered a show-stopper.
>

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.


> [...] Beyond what Ben already suggested in another post, there was also the
> more general suggestion to implicitly suppress warnings when you
> explicitly name an import. E.g.
>
>   import Control.Applicative (Applicative(..))
>
> would suppress the redundant-import warning for Applicative via Prelude,
> because we specifically requested Applicative, so we don't mind that
> Prelude re-exports the same symbol. [...]
>

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? :-/

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/a0242e30/attachment-0001.html>