[Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Rustom Mody]

On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <doug at 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
2to3 and six:
https://docs.python.org/2/library/2to3.html
http://pythonhosted.org/six/

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 :-)

]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151006/f01d7ec2/attachment.html>