<div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <span dir="ltr"><<a href="mailto:doug@cs.dartmouth.edu" target="_blank">doug@cs.dartmouth.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> littering the code with #ifdefs<br>
<br>
>  Bonus points for keeping the #ifdefs centralized<br>
<br>
Littering is the right word. "Bonus" is merely less negative points.<br>
<br>
It is ironic that the beautiful Haskell should progress by<br>
adopting the worst feature of C. #ifdef is a sticking-plaster<br>
for non-portable code. It is inserted at global level, usually<br>
to effect changes at the bottom of the code hierarchy. (Maybe<br>
in Haskell it should be a monad, in competition with IO for<br>
the outermost layer.)<br>
<br>
Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)<br>
inescapably nonportable code, such as endianity, in compilation<br>
units and #include files in a distinct part of the file system<br>
tree selected by the shell.<br>
<br>
Another trick is to use plain if rather than #if or #ifdef,<br>
and let the compiler optimize away the unwanted side of the<br>
branch.<br>
<br>
<div dir="ltr"><div><div dir="ltr"><div><br></div></div></div></div></blockquote><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any event, #ifdef is, as Simon evidently agrees, telling<br>
evidence of non-portability. It is hard to imagine an uglier<br>
"solution" to keeping up with the drip-drip-drip of Haskell<br>
evolution.<br>
<span class=""></span><div dir="ltr"><div><div dir="ltr"><div><br></div></div></div></div></blockquote></div>
</div> <br></div><div>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<br></div><div>2to3 and six:<br><a href="https://docs.python.org/2/library/2to3.html">https://docs.python.org/2/library/2to3.html</a><br><a href="http://pythonhosted.org/six/">http://pythonhosted.org/six/</a><br><br></div><div>Since the change here is trivial and pervasive why is such a tool not being considered?<br></div><div>[Or have I missed the discussion?]<br><br></div><div>In particular we can envisage a tool say 8to10 that has these modes (command-line flags)<br></div><div>--portable <br></div><div>--readable<br></div><div>--info<br><br></div><div>with the idea that <br>- portable is most unreadable (ifdef litter)<br></div><div>-
 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<br></div><div>  This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions<br></div><div>-
 info summarizes which files would change and how so that a suitable 
reorganization of the files/directories can be done prior to the switch<br></div><div> 
 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<br></div><div><br></div><div>[Whether pure is really preferable to return is another matter --<br></div><div>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?<br><br></div><div>Lets keep this note in these parentheses :-)<br></div><div><br>]<br></div><div><br></div></div>
</div></div></div></div></div><div class="gmail_extra">
</div></div>