On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> littering the code with #ifdefs

>  Bonus points for keeping the #ifdefs centralized

Littering is the right word. "Bonus" is merely less negative points.

It is ironic that the beautiful Haskell should progress by
adopting the worst feature of C. #ifdef is a sticking-plaster
for non-portable code. It is inserted at global level, usually
to effect changes at the bottom of the code hierarchy. (Maybe
in Haskell it should be a monad, in competition with IO for
the outermost layer.)

Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)
inescapably nonportable code, such as endianity, in compilation
units and #include files in a distinct part of the file system
tree selected by the shell.

Another trick is to use plain if rather than #if or #ifdef,
and let the compiler optimize away the unwanted side of the
branch.


In any event, #ifdef is, as Simon evidently agrees, telling
evidence of non-portability. It is hard to imagine an uglier
"solution" to keeping up with the drip-drip-drip of Haskell
evolution.

 
The python 2→3 transition may have caused some pain to some. However it would have been far more difficult if they had not provided tools like
Since the change here is trivial and pervasive why is such a tool not being considered?
[Or have I missed the discussion?]

In particular we can envisage a tool say 8to10 that has these modes (command-line flags)
--portable
--readable
--info

with the idea that
- portable is most unreadable (ifdef litter)
- readable is not portable -- generate a copy of the whole source tree that will have the changes and not be compatible for ghc < 7.8
  This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions
- info summarizes which files would change and how so that a suitable reorganization of the files/directories can be done prior to the switch
  This is for those library authors that would like to take the trouble to have a compatibility layer and have code as readable as possible overall

[Whether pure is really preferable to return is another matter --
For me one of the strongest criticisms of the python 2→3 switch is this that if they were going to break things anyhow why was the cleanup not more far-reaching?

Lets keep this note in these parentheses :-)

]