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

[Edward Kmett]

On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel  wrote:

> --8<---cut here---start->8---
> import Control.Applicative as A (Applicative(..))
>
> data Maybe' a = Nothing' | Just' a
>
> instance Functor Maybe' where
> fmap f (Just' v) = Just' (f v)
> fmap _ Nothing'  = Nothing'
>
> instance A.Applicative Maybe' where
> pure = Just'
> f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)
>
> instance Monad Maybe' where
> Nothing' >>= _  = Nothing'
> Just' x  >>= f  = f x
>
> return = pure -- "deprecated" since GHC 7.10
> --8<---cut here---end--->8---
>
>
Alternately,

import Control.Applicative
import Prelude

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
fmap f (Just' v) = Just' (f v)
fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where



> -- hvr
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Edward Kmett]

On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace 
wrote:

>
> On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
> > At the risk of stating the obvious: I don't think it matters from which
> > group a given argument comes from as its validity doesn't depend on the
> > messenger.
>
> In that case, I think you are misunderstanding the relevance of Johan's
> argument here.  Let me try to phrase it differently.  Some people who can
> reasonably claim to have experience with million-line plus codebases are
> warning that this change is too disruptive, and makes maintenance harder
> than it ought to be.  On the other hand, of the people who say the change
> is not really disruptive, none of them have (yet?) made claims to have
> experience of the maintenance of extremely large-scale codebases.


Very well. Let me offer a view from the "other side of the fence."

I personally maintain about 1.3 million lines of Haskell, and over 120
packages on hackage. It took me less than a half a day to get everything
running with 7.10, and about two days to build -Wall clean. In that first
day I actually had to spend vastly more time fixing things related to
changes in Typeable, template-haskell and a tweaked corner case in the
typechecker than anything AMP/FTP related. In the end I had to add two type
signatures.

Most of the patches to go -Wall clean looked like

+#if __GLASGOW_HASKELL__ < 710
import Control.Applicative
import Data.Monoid
+#endif

Maybe 10% were more complicated.

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Edward Kmett]

The part of the MRP proposal that I actively care about because it fixes a
situation that *actually causes harm* is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that
code runs often with different asymptotics depending on which one you pick.
Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ.
It means that we can't simply weaken the type constraint on mapM_ and
sequence_ to Applicative, it as a knock-on consequence it means we can't
migrate mapM and sequence out of Traversable to top level definitions and
thereby simply provide folks with more efficient parallelizable mapping
when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it
doesn't break anybody's asymptotics and it already has a sensible
definition in terms of pure as a default, so effectively you can write code
as if MRP was already in effect today. It is a wart, but one that could be
burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner 
wrote:

>
> On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink 
> wrote:
>
>> While I don't think it detracts from your argument, it seems you
>> misread the original proposal. At no point will it remove `return`
>> completely. It would be moved out of the `Monad` class and be made
>> into a top-level definition instead, so you would still be able to use
>> it.
>>
>
> Then why bother?
> If you don't intend to regard code that uses "return" as old, out-dated,
> in need of updating, etc
> If you don't intend to correct people on #haskell to use pure instead of
> return...
> If you don't tsk tsk all mentions of it in books
> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has
> a library that defines a Monad - or anyone who has a library that they want
> to keep "up to date". Do you really want to have a library where all your
> "how to use this" code has return in the examples? Shouldn't now be pure?
> Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown
> in Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!
>
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Edward Kmett]

On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne  wrote:

> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel :
>
>> [...] 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.
>

Note: You haven't been able to upload a package that has -Werror turned on
in the cabal file for a couple of years now -- even if it is only turned on
on the test suite, so any -Werror discipline you choose to enforce is
purely local.

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Edward Kmett]

On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich 
wrote:

> On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> > The part of the MRP proposal that I actively care about because it
> > fixes a
> > situation that *actually causes harm* is moving (>>) to the top
> > level.
>
> Sorry if I'm missing something, but moving (>>) is not part of the
> proposal. At least it is not mentioned on the wiki page:
>
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn
>
> Is the wiki outdated?
>

It arose during the original thread discussing the MRP but wasn't included
in the 'proposal as written' that was sent out.

https://mail.haskell.org/pipermail/libraries/2015-September/026129.html

In many ways that proposal would do better 'on its own' than as part of the
MRP.

> return itself lurking in the class doesn't matter to me all that much
> > as it
> > doesn't break anybody's asymptotics and it already has a sensible
> > definition in terms of pure as a default, so effectively you can
> > write code
> > as if MRP was already in effect today. It is a wart, but one that
> > could be
> > burned off on however long a time table we want if we choose to
> > proceed.
>
> So the cost of not moving `return` to the top level is zero?
>
> For me the cost of moving it is pretty small, just an hour or two.
> Probably recompiling all the dependencies when switching to newer
> version of GHC will take longer. (Actually I'm still using 7.8 at
> work.) But the cost is definitely nonzero.
>
> The proposal (as written on the wiki page) provides two arguments for
> the change:
>
> There is no reason to include `return` into the next standard. That is
> true.


Nobody is saying that we should remove return from the language. The
proposal was to move it out of the class -- eventually. Potentially on a
very very long time line.

But we can leave `return` is `GHC` as a compiler specific extension for
> backward compatibility, can't we?
>

This is effectively the status quo. There is a default definition of return
in terms of pure today. The longer we wait the more tenable this proposal
gets in many ways as fewer and fewer people start trying to support
compilers versions below 7.10. Today isn't that day.

There are some niggling corner cases around viewing its continued existence
as a compiler "extension" though, even just around the behavior when you
import the class with Monad(..) you get more or less than you'd expect.

Could someone please clarify what is the cost of not moving `return` out of
> `Monad`?
>

The cost of doing nothing is maintaining a completely redundant member
inside the class for all time and an ever-so-slightly more expensive
dictionaries for Monad, so retaining return in the class does no real harm
operationally.

While I'm personally somewhat in favor of its eventual migration on
correctness grounds and believe it'd be nice to be able to justify the
state of the world as more than a series of historical accidents when I put
on my libraries committee hat I have concerns.

I'm inclined to say at the least that IF we do decide to proceed on this,
at least the return component should be on a long time horizon, with a
clock tied to the release of a standard, say a Haskell2020. I stress IF,
because I haven't had a chance to go through and do any sort of detailed
tally or poll to get a sense of if there is a sufficient mandate. There is
enough of a ruckus being raised that it is worth proceeding cautiously if
we proceed at all.

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

ramin.hon...@gmail.com has indicated you're a friend. Accept?

[ramin . honary]

Hi,

ramin.hon...@gmail.com wants to follow you.

** Is ramin.hon...@gmail.com you friend? **
If Yes please follow the link below:
http://invites.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing+Listemail=Haskell-prime@haskell.orginvitername=Ramininviterid=38619668userid=0token=0emailmasterid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39from=ramin.hon...@gmail.comtemplate=invite_reg_atest=AA=txt_yes

If No please follow the link below:
http://invites.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing+Listemail=Haskell-prime@haskell.orginvitername=Ramininviterid=38619668userid=0token=0emailmasterid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39from=ramin.hon...@gmail.comtemplate=invite_reg_atest=AA=txt_no


Follow the link below to remove yourself from all such emails
http://invites.fliporamail.com/uns_inviter.jsp?email=Haskell-prime@haskell.orgiid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39from=ramin.hon...@gmail.com


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime